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GENERAL MEETING INFORMATION 



Meeting Rooms 

All meeting rooms will be in the Sheraton Palace Hotel, San Francisco. 
Specific room assignments are noted in the agenda. 

Room Reservations 

Reservations must be made by submitting the reservation card directly 
to the hotel. 

Registration 

Registration fees for COMMON cover all publication and operating 
costs and represent the only source of funds for the organization. Regis- 
tration for this meeting has been set at $30 for the entire meeting, which 
includes the cost of the luncheon on Tuesday. The registration desk at the 
hotel will be open during the following hours: 

Sunday, December 10, 1967 5:00 p.m. - 9:30 p.m. 

Monday, December 11, 1967 7:45 a.m. - 5:00 p.m. 

Tuesday, December 12, 1967 8:00 a.m. - 3:00 p.m. 

Birds - of - a - Feather Sessions 

Attendees may schedule additional informal sessions by posting a notice 
on the bulletin board. 

Systems Reference Library Publications (SRL) 

A selection of 1620, 1130, 1800, and S/360 publications are on display 
in the registration area. You may order an SRL publication by filling out 
an order form provided. You should expect to receive the items ordered 
in about 3 weeks. 

Computer Equipment Displays 

Arrangements have been made for delegates to attend demonstrations 
and receive time on the San Francisco IBM Data Center machines in- 
cluding the 1130, 360/20, 360/30, and 360/40. 

Meeting Headquarters 

Typing and reproduction services will be available in the headquarters 
room: Regency 

Agenda Notes 

The agenda listed herein represents the program at the time the booklet 
went to press. Modifications and/or additions will be noted on the informa- 
tion board in the coffee area. Abstracts for the papers listed in the program 
appear at the end of this booklet. 



LETTER TO MEMBERSHIP 
FROM PRESIDENT OF COMMON 

Members of COMMON: 

With this letter is the preliminary agenda for the December meeting 
of COMMON, in San Francisco. The September meeting in Cincinnati 
was a good one; we expect the San Francisco meeting to be better. With 
your help and cooperation, we believe that each meeting can continue to 
be better than its predecessors. 

There are several ways in which COMMON can affect IBM and the world 
in general; the majority of them, branch office, project liaison, etc., are 
for today's problems, but two are specifically for the future. The first 
is our comments and suggestions to the U.S.A. Standards Institute (USASI). 
Lynn Yarbrough, of USASI's X3.4 Committee on Programming Languages, 
will have a session on the Standards Institute: its organization, how it 
affects us, and what we can do to influence it. There will be time for 
questions and comments. 

We will have a brief discussion of the Systems Objectives and Require- 
ments Committee (SORC). This is a committee of user and IBM repre- 
sentatives, whose purpose is to provide IBM with the benefit of informed 
user opinion in determining the requirements for the next cycle. There 
will not be a formal session on SORC; their purpose is to acquire infor- 
mation, and not to dispense it. There will be an explanation of it at the 
general assembly, and there will be opportunities to discuss your ideas 
with SORC representatives. There is a serious lack of representation 
in SORC of the small computer user and process control installation. 
Remember that SORC is concerned almost exclusively with the problems 
of the future. 

We have vociferously exercised our right to criticize the products of 
both IBM and USAI; we are morally obligated to do what we can to alleviate 
the situation for the next generation. And our most important contribution 
is information about our requirements. 

See you in San Francisco. 



James C. Stansbury 



ALL ABOUT COMMON 



During the first half of the 1960's while IBM built and marketed the 
"1620" Computer, COMMON was known as "The 1620 Users Group." 
It was the "SHARE" of the small scientific computer user. All "1620" 
installations became members by applying and sending a representative 
to any one of a dozen or so regional or national meetings occurring during 
any two year period. 

As the third generation computers began to appear and it became apparent 
tha* the days of the IBM "1620" were numbered, the name of organization 
was changed to "COMMON" and a myriad of regional and national meetings 
was reduced to three national meetings per year. 

The COMMON Executive Board met in Chicago on September 15 and 16, 
1966, to discuss ways of improving the effectiveness of the organization. 
The board members felt that an organizational change was necessary to 
cope with the imminent growth of COMMON, the integration into the organi- 
zation of multiple machine types (1130, 1800, 1620, 360/30, 360/40 and 
360/44), and the development of increasing numbers of interest areas by 
the members. 

It was decided to break the organization down into four m^n divisions 
along the lines of the other two IBM User Groups "SHARE" and "GUIDE". 
Each division would be divided into projects and the projects would be 
further subdivided into working committees as needed. 

The divisions established were as follows: 

1. Systems Division. This division has broad responsibility for coordination 
of user activity and opinions in the areas of software and hardware re- 
gardless of application. 

2. Administrative Division. This division has responsibility for the various 
activities which are necessary to operate COMMON as an organization, both 
internally and in relation to other organizations. These include the news- 
letter, CAST, bylaws, membership list, program library, meeting plans, etc. 

3. Installation Management Division. This division has responsibility for 
coordinating those user activities which are concerned with the management 
of a computer installation. These include personnel training, standards, 
computing center operation, etc. 

4. Applications Division. This division has responsibility for coordinating 
user activities which are application or industry oriented. 

Each division is headed by a Division Manager who supervises the opera- 
tion of his division and reports the activities and requirements of his 
division to the Executive Board through the Executive Vice President. 
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Each division is composed of a number of projects. Each project is 
headed by a Project Manager who is responsible for specific areas of 
interest within the division and who reports to the Dvision Manager. 

Each project is divided into committees each of which is headed by a 
Committee Chairman. The committee chairmen have responsiblity for 
seeing that their committees carry out the duties within their areas of 
interest and for seeing that the consensus of opinion of the users at the 
committee meetings are transmitted to the Project Managers. 

Although in some areas committees may be divided into special working 
subcommittees dealing with specific areas, it is intended that the participa- 
tion of users in the activities of COMMON be carried out at the committee 
level. I.B.M. supplies liaison people to the established committees so that 
user's opinions and requests are transmitted to I.B.M, 

The committees meet at every COMMON meeting and these sessions are 
open to any user who has an interest in the topics covered by the committee. 
Some meetings on the agenda are listed as project meetings. Most of these 
are intended to be general discussions by groups of users having the same 
machine types and are open toall users. These sessions replace the general 
hardware meetings and problem-solving sessions that occupied much of 
the 1620 Users Group meetings. 

There are also opportunities at every COMMON meeting for users with 
special interests for which no formal project or committee exist to get 
together and discuss their problems and techniques. These are called 
"birds-of-a-feather" sessions and are organized by groups of users 
posting a notice on the bulletin board and holding a meeting. If enough 
interest persists, a committee may be formally created and meetings 
scheduled at future Common meetings. 



COMMON OFFICERS 



President 



James C. Stansbury 
Hal con International 
Two Park Avenue 
New York, New York 10016 

Secretary - Treasurer 

Charles E. Maudlin, Jr. 
Computer Center 
Texas Woman's University 
Denton, Texas 76204 

dent Western Region President 



Eastern Region Pre; 
Norman Goldman 
Boston University 
111 Cummington St. 
Boston, Massachusetts 02215 



European Region President 
(Acting) 
Dr. Hans Tompa 
European Research 

Associates S.A. 
95 Rue Gatti de Gamond 
Brussels 18, Belgium 



William G. Lane 
Director of Computer 

Sciences 
Chico State College 
Chico, California 95926 

Mid-West Region President 
Mrs. Laura B. Austin 
General Supervisor 
Computer Services 
General Motors Institute 
1700 W. Third Avenue 
Flint, Michigan 48502 



Canadian Region President 
Stuart D Baxter 

National Research Council of Canada 
Computation Centre M23A 
Montreal Road 
Ottawa, Ontario, Canada 



Board Members at Large 

Richard L. Pratt 
Data Corporation 
7500 Old Xenia Pike 
Dayton, Ohio 45432 



Paul A. Bickford 
Computer Center 
DePauw University 
Greencastle, Indiana 



Frank H. Maskiell 
McGraw-Edison Power Systems 

Division 
Box 330 

Cannonsburg, Pa. 15317 



COMMON COMMITTEE OFFICERS 

ADMINISTRATIVE DIVISION 

Manager - Laura B. Austin (3070) General 
General Motors 

Reference Manual 

Chairman - Dr. Raymond E. Roth (1715) 
State University College 

Contributed Program Library 



Chairman - Miss B. Baber (1454) 

National Education Assn. 

(Prep Forms) 

CPL Shipment Analysis (1303) 

Chairman - J. H. Keith 

Miami - Dade Junior College North 

Jug Inter- Library Exchange 



Chairman - W. A. DeLagall (1582) 
Schering Corp. 

APPLICATIONS DIVISION 

Manager - F. H. Maskiell (3081) 
McGraw-Edison Co. 

Techniques Project 



Chairman - W. Pease, Jr. (1516) 

West Virginia Pulp & Paper Co. 

Utilities 

Chairman - G. Haralampu (1041) 

New England Electric System 

Civil Mechanical Engineering 



Chairman - L. W. Brown (3301) 

International Paper Co. 

Chemical Engineering 

Chairman - G. Hertel 

U. S. Rubber Co. 



Education 

Chairman - M. Goldberg (1416) 
Fordham University 

INSTALLATION MANAGEMENT DIVISION 

Manager - C. Baker 

Pioneer Hi-Bred Corn Company 

Personnel 

Chairman - R. B. Thomas (3038) 
Federal Reserve Bank 

Operations 

Chairman - R. J Snailer (1495) 

Metropolitan Life Ins. Co. 

Standards (Inactive) 

SYSTEMS DIVISION 

Manager - J. S. Taylor (3121) 
Data Corporation 

System/360 

Project Manager - R.L. Pratt (3121) 
Data Corporation 

DOS 

Committee Chairman - D. R. Mcllvain (1100) 

Catalytic Construction Co. 

OS 

Committee Chairman - Wade Norton 

Southern Services, Inc. 

S/360-44 

Committee Chairman - A. G. Wigdahl (3134) 

Allen Brady Company 

Hardware 

Committee Chairman - J. L. Tunney, Jr. (3076) 

James R. Ahart & Associates 



360 Commercial Users 

Chairman - Mr. F. Hatfield (3008) 

Line Materials Industries 

1800 

Project Manager - C. R. Pearson (1497) 

J. P. Stevens & Co., Inc. 

(Non-Control) Software 

Chairman - R, Cox (1132) 

Humble Oil Company 

Appli cations 

Chairman - J. C. Deck (3237) 
Inland Steel Co. 

Hardware & RPQs 

Chairman - W. Barnes (531) 

Pacific Gas & Electric 

(Control) Process Systems 

Chairman - L. Jones (5046) 

Bonneville Power Adm. 

Software 

Chairman - J. K. Tanatra (3462) 

GMC Truck & Coach Division 

Hardware 

Chairman - D. L. Kraatz (5255) 

Corn Products Company 

Applications 

Chairman - Dr. W. Carlson (3009) 
Champion Papers, Inc. 

1130 Project 

Chairman - D. Dunsmore (3428) 

Ohio River Valley Commission 

1620 Project 

Chairman - Richard Ross 

University of Mississippi 



SESSION M. 0. 
Monday 8:00-8:45 a.m. 
M.O. 1 New Members Sessi on 

Chairman: James Stansbury, President 
Room: Comstock 

Subject: Topics of interest and concern for those attending 
COMMON for the first time. 

M.O. 2 Session and Panel Chairmen Briefing 

Chairman: Robert Forstrom 

Room: English 

Subject: General information and arrangements briefing 
for session and panel chairmen. 
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SESSION M. 1 



Monday 9:00-10:00 a.m. Q 

M. 1. 1. General Session 

Chairman: James Stansbury, President 
Room: Rose 

Subjects: a. Introduction of COMMON Officers and IBM 
Representatives. 

b. Reports from Divisional Chairmen 

c. Secretary- Treasurer's Report 

d. Arrangements Chairman's Announcements 

e. Program Chairman's Announcements 

f. Announcements by Members 

g. Announcement of Chicago Meeting 

COFFEE BREAK 10:00 - 10:30 
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SESSION M.2 
Monday 10:30 - 12:00 Noon 



M.2.1 360 Project 

Chairman: Richard Pratt 
Room: Rose 

Subject. a. COBOL to PL/1 Conversion: IBM 
b. FORTRAN to PL/1 Conversion: IBM 



M.2.2.. 1130 Project 



7 



Chairman: 

Room: 

Subject: 



Dave Dunsmore 
California 

w a. Dynamic Model Simulator for the IBM 

1130: George Polyzoides 
, b. Three-and-Four-Bar Linkage System with 

Plotted Output: Robert Cushman 



M.2.3 1620 Project 

Chairman: Richard D. Ross 
Room: Golden Gate 

Subject: Tutorial Sessions Non-IBM Compilers 

a. Data SPS: Richard Ross 

b. One Dimensional Blast Wave Theory For 
Explosions: J. Goresh and J. Caslin 

c. Discussion of Related Topics 

M,2.4 1800 Project 

Chairman: Robert Forstrom 

Room: Comstock 

Subject: Multiprogramming Execu- 
tive, MPX: D. Schade (IBM) 

M.2.5 Numerical Control Project 
Chairman: J. Moschetti 
Room: Royal Suite (262) 

Subject: Discussion of Problems Relating to Numerical 
Control. 
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M.2.6 Installation Management and Administration 
Chairman: Laurence Baker 
Room: Forty-Niner 

Subject: ""a. Systems Reference Library SRL: G. Goesch 
(IBM) 

c/b. Program Library Discussion: L. Austin 
PREP forms for 1130, 1800 
and 360 libraries 
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M.3.1 360 Project 
Chairman: 
Room: 
Subject: 



M.3.2 1130 Project 
Chairman: 
Room: 
Subject: 

M.3.3 1620 Project 
Chairman: 
Room: 
Subject: 



M.3.4 1800 Project 
Chairman: 
Room: 
Subject: 



SESSION M„ 3 
Monday 1:30 - 3:00 p.m. 

Richard Pratt 
Rose 

a. OS/DOS Data Management: 
(IBM) 

b. OS/DOS Linkage Editor: 
(IBM) 



William Post 
William Post 



Dave Dunsmore 
California 

Monitor Version II: G. Lester (IBM) 

Tony Ross 
Golden Gate 

Tutorial Session (Continued) 

a. Kingston and Forgo FORTRAN: 
F. Windham and G. Smith 

b. A Batch Processing FORTRAN system for a 
minimal configuration 1620: Gaylord Henry 

c. Discussion of Related Topics 

Robert Forstrom 
Comstock 

1800 MPX: B. Lanek (IBM) 
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M.3.6 Numerical Control Project 
Chairman: J* Moschetti 
Room: Royal Suite (262) 

Subject: Discussion of Problems Relating to Numerical 
Control 



M.3.7 Installation Management 

Chairman: Laurence Baker 
Room: Forty-Niner 

Subject: 360 Operator Training: H. Cadow (IBM) 

M.3.8 Administration 

Chairman: L. D. Yarbrough 

Room: Bonanza 

Panel Discussions: USASI Standards 

Panelists: T. B. Steel, Jr., Chairman, USASI X3.4 
L. D. Yarbrough, X3.4 and COMMON 
(Others to be announced) 

Subject: a. Introduction to USASI: Mr. Steel 

b. Current USASI Activities: Mr. Yarbrough 

c. Fortran: USASI vs 1620 vs 360 

COFFEE BREAK 3 : 00 - 3:30 p.m. 
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M.4.1 



SESSION M.4 
Monday 3:30 - 5:00 p.m. 
360 DOS Committee 
Chairman: Don Mcllvain 
Room: Rose 
Subject: SOUND-OFF 



Members sound off to IBM regarding suggestions, 
problems and needs for DOS. 



M.4.2 360 OS Committee 

Chairman: ' O. B. Anderso n \M APf AJ«£fd*/ 

Room: Royal Suite (264) 

Subject: SOUND-OFF 

a. Members sound off to IBM regarding suggestions, 
problems and needs for OS. 

b. Organization of OS Committee 
M.4.3 360-44 Committee 

Chairman: Allen B. Wigdahl 

Room: Royal Suite (260) 

Subject: SOUND-OFF 

Members sound off to IBM regarding suggestions, 
problems and needs for System 360-44. 



M.4.4 1130 Project 



Chairman: Dave Dunsmore 
Room: California 

Subject: Continuation of monitor 
Ver II: G. Lester (IBM) 



SOUND - OFF For System 1130 will 
be Held 7 ; 30 to 9:00 p.m. 



M.4.5 / 1 620 Project 
Chairman: 
Room: 
Subject: 



M.4.6/ 1800 Project 
Chairman: 
Room: 
Subject: 



M.4 .9 



Frank Windham 
Golden Gate 

Monitor I Papers 

a. A Large 1620 DOS, Reasonably 7094 
Compatible: Lanny Hoffman 

b. Basic Problems of Information Retrieval 
and a Solution on the 1620: Lanny Hoffman 

c. Discussion of Monitor I 



Robert Forstrom 
Comstock 

Teleprocessing Support on 1800/1070/1050/2740/ 
1030: R. Smith (IBM) 



M.4.^/ T echniques Project 

Chairman: W. Pease 
Room: Parlor A (214) 

Subject: >/ a. Fast Fourier Transforms with Applications 
for the IBM 1800: Joe Howard Smith 
b. NIMS - The Aerospace Scientific Data Re- 
duction Monitor System: Charles R. Aumann 

M.4.8 C , Installation Management 

Chairman: Laurence Baker 

Room: Forty-Niner 

Subject: a. Standards in Operation: D. Fuiz (IBM) 

\J b. Investigation of Abnormal Operation Conditions: 
K. Anderson (IBM) 

Administration 
Chairman: L. D. Yarbrough 
Room: Bonanza 
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z Subject: Current Research Concerned with the Standard- 
ization and Formal Definitions of PL/1: Dr. J.A.N. 
Lee 



c 



T.l.l 360 Project 
Chairman: 
Room: 
Subject: 



T.1.3 800 Project 



SESSION T. 1 
Tuesday 8:30 - 10:00 a.m. 

Richard Pratt 
Concert 

a. A Small OS System: Wa$tf Norton 

b. Panel Discussion: Does OS Belong in 

COMMON? 



Chairman: Robert Forstrom 
Room: Comstock 



PL-1 Language Development COP: C. Burwick 
(IBM) 



Subject: 

T.1A Electric Utility Project - 1130 Working Group 



Chairman: S. A. Clark 
Room: Golden Gate 

Subject: 



a. 1130 Load Flow 

b. 1130 Short Circuit Calculations 



T.1.5 Electric Utility Project - 360 Working Group 

Chairman: O. B. Anderson, Jr. 

Room: Royal Suite (260) 

Subject: a. 360 Load Flow 

b. 360 Short Circuit Calculations 
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T.1.6 Electric Utility Project * 1800 Working Group 

Chairman: R. W. Page 

Room: English 

Subject: a. I860 Load Flow 

b. 1800 Short Circuit Calculations 



T.1.7 ^ Techniques Project 

Chairman: W. Pease 

Room: Parlor A (214) 

Subject: a. Data Collection: G. A. Gallaway 

J b. Large Matrix Inversion on a Small Computer 
T. E. Bridge 

/ 

T.1.8 ^ Education Project 

Chairman: Jack Underwood 



Room: Bonanza 

Subject: ^a. Chico State College Registration/Scheduling 
Analysis: Neil Mclntyre 

Student Information System of Christian 
Brothers College Employing the IBM 1130: 
Brother Jerome Wegener 



T.1.9 Installation Management 

Chairman: Laurence Baker 
Room: Forty-Niner 

Subject: V a. Programmer Expectation: D. Mayer (IBM) 

b. Programmer Selection and Testing: 
D. Mayer (IBM) 

COFFEE BREAK 10:00 - 10:30 
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T.2.1 360 Project 
Chairman: 
Room: 
Subject: 

T.2.2 1130 Project 
Chairman: 
Room: 
Subject: 

T.2.3 1800 Project 
Chairman: 
Room: 
Subject: 




SESSION T.2 
Tuesday 10:30 - 12:00 Noon 

Richard Pratt 
Concert 

44PS and its differences from OS: D. Rumney (IBM) 

Dave Dunsmore 
California 

1130 as a Terminal for S/360: K. Gabbert (IBM) 

Robert Forstrom 
Comstock 

a. Installation Descriptions 

Bonneville Power: B. Hoffman 

Colorado Public Service Corp: E. McLaughlin 

b. 8 810 mil, ft, C i mift i l 



T.2.4 Electric Utility Project - 1130 Working Group 
Chairman: S. A. Clark 
Room: Golden Gate 

Subject: a. 1130 Hardware Difficulties 

b. Sound Off 

c. New business 

T.2. 5 Electric Utility Project - 360 Working Group 
Chairman: O.B. Anderson, Jr. 
Room: Royal Suite (260) 

Subject: a. 360 Hardware difficulties 

b. Sound off 

c. New business 
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T.2.6 Electric Utility Project - 1800 Working Group 
Chairman: R. W. Page 
Room: English 

Subject: a. 1800 Hardware Difficulties 

b. Sound off 

c. New business 

Techniques Project 
Chairman: W. Pease 
Room: Parlor A (214) 



Subject: U a. Non-linear Regression Analysis with three 
Independent Variables: T.E. Bridge 

b. User Experience with 1130 LP-Moss: S. A. 
Lynch 

T.2.&/ Petro Chem Engineering Project 
Chairman: Gene Hertel 
Room: Forty-Niner 

Subject: Application of Simulation in Control, Design and 
Optimization of Chemical Processes: M.J. Shah 
(IBM) 

T.2.9 Education Project 

Chairman: Jack Underwood 
Room: Bonanza 

Subject: Panel Discussion on Software Requirements in 
an Instructional Program 



C 
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DELEGATES LUNCHEON 

Tuesday 12:00 Noon 
Rose Room 




Speaker: Dr. Robert E. Hill 

President, Chico State College 

Dr. Hill is a recognized authority in the 
field of international education, finance, in- 
vestment, and international economics. He 
has written numerous articles, monographs 
and short papers and has risen from Assis- 
tant Professor of Finance (1957) at the 
University of Illinois to Professor of Busi- 
ness and President of Chico State College 
(1966). 

Dr. Hill will speak on the subject: ' 'Tech- 
nology and Administration; A Paradigm/' 



SESSION T.3 
Tuesday 1:30 - 3:00 p.m. 

T.3.1 Special Session: Time-Share Computing 
Chairman: W, G. Lane 
Room: Concert 

Subject: a. Conversational Computing: James Babcock 

b. RUSH, Conversational PL-1: Paul DesJardine 

c. Computer Assisted Instruction at Stanford 
University: Max Jerman 



T.3,2 360-44 Committee 



Chairman: 

Room: 

Subject: 

T.3.3 1800 Project 
Chairman: 
Room: 
Subject: 



Allen B. Wigdahl 
Royal Suite (260) 

Division of Problems related to System 360-44 

Robert Forstrom 
Comstock 

PROSPRO: O. Merklinghouse (IBM) 



T.3.4 Electric Utilities Project 

Chairman: G. S. Haralampu 

Room: California 

Subject: a. Reports of Working Groups 

b. Progress reports on fault calculations, 
transient stability engineering operating 
systems 

T.3.5 Petro Chem Engineering Project 



Chairman: 

Room: 

Subject: 

T.3.6. 1130 Project 
Chairman: 
Room: ) 
Subject: 



Gene Hartel 
Forty-Niner 

Laboratory Automation: R A. Edwards (IBM) 

Larry Armbruster 

LP-MOSS: IBM 
COFFEE BREAK 3 : 00 - 3 : 30 p.m. 
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SESSION T.4 
Tuesday 3:30 - 5:00 p.m. 
T.4.1 Open Board Meeting 

Chairman: James Stansbury, President 
Room: Rose 

Subject: a. Members Sound Off to Board 

b. Discussion of IBM-COMMON Relations 

c. COMMON Publications 

T.4.2 , 1800 Project 

S 

Chairman: Robert Forstrom 

Room: Comstock 

Subject: a. PROSPRO (continued): O. Merklinghouse (IBM) 
(y/b. TSX Modification for 6 Disk Drives: 
E.H. Spencer 

T.4.3 Electric Utilities Project 

Chairman: G. S. Haralampu 
Room: California 

Subject: a. Engineering Data Banks 

b. New Business 

c. Plans for next meeting 
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SESSION W.l 
Wednesday 8:30 - 10:00 a.m. 
W.l.l 360-OS Committee 

Chairman: f\ v ffi, Arif1nrronf#r. \Pf\$C K)0(LT6ki 

Room: Royal Suite (264) 

Subject: a. OS Reread in FORTRAN: Wa$|J Norton 

W.1.2 360-DOS Committee 

Chairman: Don Mcllvain 

I A . 4 l Room: Ralston 

y\ Subject: a. Discussion of problems related to FORTRAN 

r under DOS ^ 

W.1.3 360-Commercial Committee 

Chairman: To be announced 

Room: Royal Suite (262) 

Subject: a. Discussion of problems related to 
COBOL, RPG, COS 

W.l. 4 360-44 Committee 

Chairman: Allen B. Wigdahl 
Room: Royal Suite (260) 

Subject: Discussion of problems relating to System 360-44 
W.1.5 1130 And Techniques Projects 
Chairman: Dave Dunsmore 
Room: Bonanza 

Subject: a. Overlapped printing for IBM 1130 Commercial 
Applications Using FORTRAN Write Statement: 
Brian Swain 

b. 1130 Commercial Subroutines 
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W.1.6 



1620 Project 



Chairman: 
Room: 
Subject: 

W.l/L/ 1800 Project 



Richard Karpinski 
Golden Gate 

General information on CAI with special 
emphasis on 1620 version of COMPUTEST 



Chairman: Robert Forstrom 
Room: California 

Subject: ($/ A comparison between 2310 and 2311 Disk 
Z« Storage Systems: Salomon Saroussi 
-» \J^Jp Process Control in Natural Gas Transmission: 



I Z *3 ~ v -^ r A. A. Douloff 
W.1.8 Administration Project 




Chairman: Laura Austin 
Room: English 

Subject: a. Discussion of Reference Manual Project 
b. Call for help 



1.9 Installation Management 



Chairman: Laurence Baker 
Room: Forty-niner 
Subject: 



Systems and Programming Project Management: 
Ralph Sack man, Jr. 



COFFEE BREAK 10:00 - 10:30 a.m. 
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SESSION W.2 
Wednesday 10:30 - 12:00 Noon 
W.2.1 360-OS Committee 

Chairman: ^, °, ^nrirnn ,TLl V f fttiC NOfcTdlJ 

Room: Royal Suite (264) 
Subject: RAX: D Madden (IBM) 
W.2.2 360- DOS Committee 

Chairman: Don Mcllvain 
Room: Ralston 

Subject: Discussion of problems relating to PL-1 
W.2.3 360-44 Committee 

Chairman: Allen B. Wigdahl 
Room: Royal Suite (260) 

Subject: Discussion of problems relating to System 
W.2.4 1130 Project 

Chairman: Dave Dunsmore 
Room: Bonanza 

Subject: Discussion of problems relating to 1130 
W.2.5 1620 Projefl ^S^P lii* • 

Chairman: Richard Ross 
Room: Golden Gate 

Subject: a. Continuation of CAI discussion 

b. Suggestions and Wind up 

c. Plans for next meeting 
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Robert Forstrom 
California 

Subject: a. User Experience with Teletype Terminals 
on the IBM 1800: W. M. Schonlau 
b. Plans for next meeting 

W.2.7 Techniques Project 

Chairman: W e Pease 

~ Room: English 

* Subject: a. Summation and Review 

b. Plans for future meetings 

W.2.8 Petro Chem Engineering Project 

Chairman: Gene Hertel 

Room: Royal Suite (262) 

Subject: a. Summation and Review 

b. Plans for future meetings 



W.2.6 1800 Project 
Chairman: 
Room: 



W.2.9 Installation Management 



Chairman: Laurence Baker 

Room: Forty-Niner 

Subject: A Review of the GUIDE Installation 

Management Project: Arthur Nichols 



-27- 



SPECIAL ATTRACTION 



Wednesday Afternoon 
IBM San Jose Plant Tour 

a. 1500 and 1800 Production line 

b. Direct access storage devices 

c. Demonstration of 1800 MPX 

Complementary Transportation by IBM Charter Bus 
Leave San Francisco 1:15 PM 

Rtn San Francisco Airport 4:45 PM 
Rtn San Francisco 

(Sheraton Palace Hotel) 5:30 PM 

Reservations must be made at the registration desk by 12:00 
Noon Tuesday. 

Delegates may choose to tour the facilities 
( a and b) or to attend the demonstration 
(c). We regret that time does not permit 
both. 



SESSION W..3 
Wednesday 1:30 - 3:00 PM 

Richard Pratt 
Ralston 

a. Reports of 360 committees 

b. Recommendations to IBM 

c. Plans for future meetings 

Dave Dunsmore 
Bonanza 

a. Suggestions and Improvements 

b. Plans for future meetings 
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W.3.1 360 Project 
Chairman: 
Room: 
Subject: 

W.3.2 1130 Project 
Chairman: 
Room: 
Subject: 



Abstracts of Papers 



Session M.O 

M.0.1 New Members Session 

At past meetings the orientation session for new members of COMMON 
has always taken place at the end of the first day. This arrangement 
has the result of permitting many new members to walk around in a 
fog for one-third of the meeting! In an attempt to remedy this situation 
we have scheduled a short session before the meeting proper begins to 
familiarize new members with the workings of COMMON and to make them 
feel more at ease at the sessions that follow. 

Session M.l 

M.l.l General Session 

This meeting will be chaired by the president of COMMON, Mr. 
James Stansbury and will be in the nature of a formal welcome to the 
attendees from the Executive Board. There are no concurrent sessions, 
so that all registrants may be present. In addition to the usual introduc- 
tions of COMMON Officers and special guests there will be time reserved 
for last minute changes to be announced by the Arrangements Chairman 
and the Program Chairman. If possible, procedural questions from the 
floor will be invited. 

Session M.2 

DYNAMIC MODEL SIMULATOR FOR THE IBM 1130 

The Dynamic Model Simulator is a chain of FORTRAN source programs 
that permits the IBM 1130 user to investigate in depth the dynamic behavior 
of physical systems that can be modeled into linear or nonlinear ordinary 
differential equations. 

It can be used for the investigation of a wide range of engineering 
and mathematical problems from reaction kinetics and reactor responses 
to the design of electrical networks and structural assemblies. 

The system does not require familiarity with analog computers al- 
though in a way it forces the IBM 1130 hardware to perform the function 
of an analog computer while at the same time it offers the digital computer 
advantages of random memory access and ten digit (extended) precision. 

The input consists of English command words (START, WAIT, RESET, 
etc.) and numeric data which are read in free format. 

The system output includes tabulated values of the variables at specified 
intervals, a table of the variables involved and detailed error and infor- 
mation messages. Plotting of the variables is also available as an option. 
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System Source Language: FORTRAN IV, Level E 



System Hardware Requirements: 



1131 CPU-8K, one 2315 disk cartridge 
1442 Card Reader 

1132 Printer 

Benson-Lehner 305 Digital Incremental 
Plotter (optional) 



PROGRAM LIBRARY 

Discussion of the proposed PREP Forms for the 1130, 1800 and 360 
Library. There will also be a discussion of an extension of the minimal 
standards for this Library. It is requested that there be representatives 
from each of the machine system projects in the Systems Division pre- 
sent at this meeting. 



THREE-BAR AND FOUR-BAR LINKAGE SYSTEM WITH 
PLOTTED OUTPUT 



A mathematical model of a linkage system is controlled by an array 
of inputs to plot out the path of the linkage intersection point. In addition, 
the system simulates turning the entire mechanism about a major axis. 
The output of the system has yielded some very interesting designs. 

In conjunction with this report, a list-oriented free field floating point 
input program has been developed. This routine enables the control 
program to modify only specified items of the system input. Under break 
character control, an automatic interactive procedure can be set up. 



Session M.4 



'A LARGE 1620 DISK OPERATING SYSTEM, REASONABLY 
7094 COMPATIBLE. ' 

A new monitor for a 40K or 60K 1620 has been developed at Princeton 
for use as a debugging aid for the 7094 and some 360/OS programs. 
FN II I/O and FN IV I/O are included as well as private storage of pro- 
grams. Many control card options exist. Speed can be 2 to 4 times faster 
than MON-I (if one has hardware FLT. PT.)both in compilation and execu- 
tion. A users manual does exist. Many students are presently using the 
system on a completely op en- shop basis. 
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'BASIC PROBLEMS OF INFORMATION RETRIEVAL AND A 
SOLUTION ON THE 1620.' 

Some of the basic problems of information retrieval and implementation 
are discussed. The techniques of file-organization are discussed. These 
techniques are discussed for the most common file devices (disk and tape). 
A solution is shown for the 1620 with disk to demonstrate disk utility. 



FAST FOURIER TRANSFORM 
WITH APPLICATIONS FOR THE IBM 1800 

The Fast Fourier Transform technique as developed by Cooley and 
Tukey has had a widespread effect in the field of time series analysis. 
However, some difficulty has been encountered by potential users in 
determining exactly how the technique works. An effort to explain the der- 
ivation in detail will be made 

Also, a description will be given of an analysis package program in 
which the Fast Fourier Transform technique is used to yield amplitude/ 
phase spectra, power spectra, cross power spectra, and auto correla- 
tions. 



NIMS- THE AEROSPACE SCIENTIFIC DATA REDUCTION 
MONITOR SYSTEM 



The IBM-TSX System was designed for an IBM - 1800 operating 
in a real time environment as a process controller. The Aerospace 
IBM- 1800 is used primarily as a post flight data reduction system in- 
teracting with telemetry ground station equipment. This demands the 
full interrupt facilities of the system but in a batch processing mode of 
operation such as offered by the TASK stand alone type system. The 
resulting NIMS Monitor System combines the features of the process 
and non-process modes of operation into a general mode of operation 
in which the full interrupt and peripheral facilites of the machine are 
available to the active application program under execution. 

The system basically is a TASK OFF-LINE system with the system 
components modified to allow Process Subroutines and Interrupt Service 
Subroutines to be included in the core load generation. Other features 
include a one card cold start, ability to assemble or compile from magnetic 
tape input, and a magnetic tape backup system. In addition, the TRACE 
and CORE DUMP routines of TASK have been modified to provide and 
extended mnemonic output listing. 
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CURRENT RESEARCH CONCERNED WITH THE STANDARDIZATION 
AND FORMAL DEFINITION OF PL/I 



In April 1966, a subcommittee of USASI Task Group X3.4.2 was 
established to investigate the standardization of PL/I. Since that time, 
two working committees have established with exolicit charters: 
Group I: The resolution of the language PL/I 

and 

Group II: Formal Definition of PL/I 
This paper deals specifically with the work of the committee on Formal 
Definition and its relations with the definitional task forces within IBM. 
This paper will discuss the techniques of definition as proposed by the 
committee, the uses to which the definition is to be put and the implications 
of the work of this committee on the standardization of other computer 
languages. 

A familiarity with PL/I is not presumed. 



Session T. 1 



THE 1620 AS A DATA COLLECTOR OR 
SOFTWARE, THE CRUTCH HARDWARE BOYS LEAN ON 



The paper will cover the date collection methods used at the Sacramento 
Peak Observatory. The principle reasons for designing a computerized 
data collection system were : 

1) Improve existing methods which used summary punches. 

2) Gain experience and insight into problems associated with data 
collection in preparation for third generation equipment. 

The paper will also cover the roles played by the programming staff 
in this type of operation. Namely, software as a diagnostic tool for the 
hardware boys in developing data reduction/collection instruments, and 
software as a useful and flexible tool for the research scientist. 

Three methods for data collection and reduction by computer have 
been tried. 

1) On line, one point at a time, testing each point for parity and 

structural errors and storing it on the disk before the next 
point is generated. 

2) On line, a record at a time, locking the source device out until 
the data has been tested and stored. 

3) Off line, using 7 track incremental tape recorders, with testing 
and reduction being done during slack times. 
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CHICO STATE COLLEGE REGISTRATION AND 
SCHEDULING ANALYSIS 



"Salient features of Chico State College's computer approach to 
student scheduling and registration are discussed; applicability to other 
colleges and other computer configurations is emphasized." 



STUDENT INFORMATION SYSTEM OF CHRISTIAN BROTHERS 
COLLEGE EMPLOYING THE IBM 1130 



We received our 1130 around July 4 and immediately began programming 
it for our Student Information System. This is a great improvement over 
the 1620 system since that was chiefly card oriented and we can now keep 
all the information on the disk. All of the programs are written in FORTRAN 
with the exception of two or three adapted with the Commercial Subroutine 
Package. After the students are registered, we are able to produce class 
lists, student schedules, mailing labels, all types of statistics, statements, 
report cards, and permanent record labels. The system works very well 
and will become more efficient when we add an additional two disks and 
receive our 1403 printer. 
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Session T. 2 



USER EXPERIENCE WITH 1130 LP-MOSS 



U. S. Reduction Co. has used the 1130 LP-MOSS application package 
since its first release. Various problems have been encountered during 
its use; however, useful answers have been obtained. Due to the size of 
the aluminum alloy blending problem being studied, a second 1130 had to 
be leased for full dedication to this problem. Early results indicate a 
reasonable payback may be obtained from this hardware and software 
combination. 

An Outline 



1. Company background 

2. Early uses of linear programming 

3. Problems encountered in implementing 1130 LP-MOSS 

4. Results to date and future planning 

5. Specific application modifications desired 



APPLICATION OF SIMULATION IN CONTROL, DESIGN AND 
OPTIMIZATION OF CHEMICAL PROCESSES 



The problem of supervisory control and optimization of a chemical 
process requires that the control as well as the optimization programs 
be provided with a mathematical relationship between the dependent and 
independent variables in the process. 

In this presentation we will discuss methods of arriving at this relation- 
ship based on the fundamental laws of physics and chemistry. We will 
make the proper approximations valid for control purposes to obtain 
the solution of the differential equations, describing this relationship. 
Use of simulation languages helps in reducing the programming time as 
well as the number of trials required to attain successful solutions. 

An example of methanol plant will be discussed in some detail to illus- 
trate the mathematical and programming techniques to achieve the desired 
relationships for control and optimization. It will be shown how these 
differential equations with modification of the objective function when 
used in the optimization program can lead to optimum design of the plant. 
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Session T.3 



LABORATORY AUTOMATION 



The session on Laboratory Automation will include a general description 
of programming and equipment aspects of the application of the 1800 and 
1130 to this newly emerging and fast growing field. Following this 
discussion, an application will be discussed in detail. This will include 
a description of the type of research to be accomplished, the incentives 
of the on-line computer, the programming system to run the instrument 
in a closed loop fashion, and other experiences to date with the system. 
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Session W.l 



OVERLAPPED PRINTING FOR IBM 1130 COMMERCIAL 
APPLICATIONS USING FORTRAN WRITE STATEMENT. 



A method is described for incorporating overlapped printing into 
IBM 1130 Commercial FORTRAN programs. Communication to the sud- 
subprogram which performs a printing operation is acnievea tnrough 
the FORTRAN WRITE statement rather than through the CALL statement. 
The advantage of this method is that limited use can be made of the 
formatting ability of the FORTRAN language. Headings can readily be 
incorporated, and the layout of the printed page specified by use of FORMAT 
statements. 



A BATCH PROCESSING FORTRAN SYSTEM 
FOR A MINIMAL CONFIGURATION IBM 1620 



This paper describes a software package designed to increase through- 
put on a 20K card system IBM 1620 computer in an environment where 
a large number of fairly simple FORTRAN programs must be processed. 
The increase in throughput is accomplished in two ways; (1) programs 
are batch executed under control of a loader- monitor routine, and (2) 
a powerful precompiler reduces the number of execution errors and de- 
creases the requirement for on-line debugging. 

The compiler is a version of the PDQ FORTRAN compiler which 
has been modified to handle the batch processing features of the system. 
Batch execution is made possible by keeping the entire subroutine library 
resident in core rather than reloading it with each object deck. Object 
programs, separated by control cards, are stacked for input. The reading 
of a control card by the FORTRAN card read subroutine or the execution 
of a CALL EXIT statement will cause the next object deck to be automat- 
ically loaded and executed. The monitor will also terminate a job if the 
output line count exceeds a control card specification. 

The precompiler detects more than seventy distinct errors based on 
PDQ FORTRAN specifications. Many of these errors, such as undefined 
symbols, are undetected by the compiler and cause execution check- 
stops. Recognition of multiple errors in a single statement is possible, 
thus eliminating multiple debugging passes. 
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A COMPARISON BETWEEN 2310 AND 2311 DISK STORAGE SYSTEMS 



A series of programs has been written to allow 1800 users to fully 
utilize the capabilities of the IBM 2841-2311 disk storage system within 
the frame work of the Time-Sharing Executive — TSX, Version 3, Mod 1. 

A comparison is made between the 2311 and the 2310 disks in pro- 
gramming techniques, timing and cost effectiveness. 



PROCESS CONTROL IN NATURAL GAS TRANSMISSION 
WITH AN IBM, 1800 



This paper will present the progress made by Trans-Canada Pipe 
Lines Limited, Toronto in the field of process control computers. A 
brief description is given of the feasibility study prior to ordering the 
computer, the organization of the implementation team and the methods 
of implementation. 

The purpose of installing the process control computer at Trans- 
Canada is to save fuel by more efficient operation of compressor stations, 
and to guide the dispatcher into better control of the line, thus allowing 
more throughput at the same or better operating cost. The computer is 
not closed loop, but accepts telemetered data from all compressor 
stations on a priority interrupt basis, optimizes the line by means of an 
on-line simulation program and then informs the dispatcher by type- 
writer output what change, if any, to make to achieve optimal operation. 

A description is given of the telemetering system that feeds the 
computer and of the simulation/optimization program that is used to 
control the line. The computer, the I B o M. 1800, was installed in June 
1967. 



SYSTEMS AND PROGRAMMING PROJECT MANAGEMENT 



The allocation of limited systems and programming resources to the 
highest payoff areas is becoming more important as data processing in- 
stallation costs continue to rise. Long and short-range plans properly 
approved by top management and formalized systems project management 
are vital tools to assure that systems capability is focused on the major 
areas of the enterprise and adequately controlled to attain the stated ob- 
jectives. To work effectively in this environment, additional demands 
are placed onto the systems group to develop systems plans in terms 
easily understood by top management and onto data processing man- 
agement to bring about fulfillment of the approved plans on time and as 
economically as possible. 
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Session W.2 



USER EXPERIENCE WITH TELETYPE 
TERMINALS ON THE IBM 1800 



The following describes and addition to the programming system for 
the IBM 1800 computer. The expanded system will support up to 16 remote 
teletype terminals being used in a time-sharing environment primarily 
to solve realtime information processing problems. 

1800 Hardware 



The 1800 CPU makes extensive use of hardware interrupt levels and 
data channels to operate its standard data processing I/O equipment. In 
addition the 1800 can have analog and digital I/O capable of communicating 
directly with almost any kind of equipment. The terminal system uses 
2 words of digital input and 1- word of digital output (16 bits/word) to 
control all 16 terminals simultaneously. No data channels or additional 
hardware are employed. 

TSX Programming System 

The 1800 programming system provides many conveniences. Programs 
are of two types, process and non-process. 

Process programs can be initiated by externally generated interrupts 
or can be queued by any program for execution. They can be a part of the 
system skeleton which is in core at all times or they can be kept on disk 
in core-image form. Process programs have highest priority and generally 
use some analog or digital I/O. 

Non-process programs ordinarily do not use the process (analog and 
digital ) I/O. They are usually stacked jobs of a conventional type to be 
run under the non-process monitor. 

When time-sharing, the system does the following: 

(1) . Runs non-process programs for background (job shop). 

(2) . Periodically checks the queue for process programs. 

(3) . Permits externally or internally generated interrupts to 

load and execute process programs at any time. 

Both (2) and (3) require that the non-process job be saved and restored 
when the process work is finished. 

The Terminal System 

The terminals extend the time-sharing capabilities of the system by 
allowing up to 16 users to communicate with the system simultaneously. 
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Terminal activities include: 



(1) , Queing process programs for execution. 

(2) . Communicating with programs during execution. 

(3) . Programming in NUtran (conversational fortran). 

Many other activities are planned. 

Most of the terminal system capabilities are achieved by simply 
making the standard TSX functions more accessible. The only programming 
efforts unique to the terminal system are the communications controller 
(simulated by an in-skeleton program), and the time-slicing of terminal 
service programs. 
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3 42 8 


CINCINNATI OHIO 


1 1 30 


DYE 


D 


R I B i • i H A W THOR N E N o Y_. 








ELENBAAS 


J 


A DOW CHEMICAL 


3612 


MIDLAND MICH 


1 1 30 


ELMER 


C 


MI BM . 




WHITE PLAINS N.Y. 




EMERSON 


J 


T FRESNO S T A T E COLL E GE 




FRESNO CALIF 


162 


ER I CSON 


J 


OCENTURY ELECTRIC CO 




ST LOUIS MO 


113 


FAROUGH I 


S 


CH A M P I N PARE R S I N C 




PASADENA TEXAS 


1800 


FAR WELL 


R 


AUMIV OF ALBERTA 




EDMONTON ALT A CANADA 


180 


FELDMAN 


M 


N . Y « M E D I C A L C OL L E GE 




NEW YORK N.Y. 


360 


FERRAL 


R 


L U S W B SACRA M E N T R F C 




SAC R A i'i El\ TO C A L 1 F 


G 















PAGE 


3 


■ F^IER 


D 


GUNIV OF ALBERTA 




EDMONTON ALBERTA CANADA 


18 


F ITZPATR ICK 

FOERSTER 


E 
C 


DILL I NO IS STATE UN IV 
SIBM PC -1- SSS 


3 2 95 


NORMAL ILL 

SAN JOSE CAL IF 




1 1 30 
1 8 


FORSTR H 
FORSYTH 


R 
D 


W N R T H A I ; E R ROCK W ELL 
.CONTINENTAL CA.N...CQ 




Y R B A L INDA CAL IF 
CH..LCAGCL- UJ- JNrVLS 




18 00 
..,1,6.2!) 


FOUTS 
FOX 


C 
D 


A US ARMY CORPS OF EMG 
RGMC TRUCK + COACH 




PORTLAND RE G 
PONT I AC MICH ' 




1 8 00 
1 8 


FR ANNE A 
FR ICKE 


J 

E 


A MOBIL OIL CORP 
CL INF I ELD COLLEGE 


54 7 


MIDLAND TEXAS 

MC M1NMVILLE RE G 




1 i 30 

1 62 


FR I EDM AN 
FR I EDLAND 


J 

M 


LKAISER ENGINEERS 

JUS_. PUBLIC h'tAL T H „S E RV 




OAKLAND CALIF " 
.LAS VEGAS NEV AD A„ 


1130 

^ 11 3 


FULL AN 
GANATRA 


D 
B 


J I B M C OR P 




W H I T E PL A I N S N • Y • 

DETROIT MICH 




360 


GANATR A 
CARD 


J 

D 


KGENER A L M TORS CO R P 
A I R M 




PONT I AC MICH 
HAVERSTRAW N.Y, 




1 8 00 
1800 


GARDNER 
GHISELL I 


D 
J 


SGENER A L F 1 J D S C hi P 
F AIRCH ILD 




TAR'RYTOVIN N.Y. 
MT VIEV/ CALIF 




1 1 30 

3 6 


G I L.BERT 
GLADFELTER 


D 
G 


MPUBL I C SER V I CE CO 
W S D S CM L fv; I fx E S TEC hi 


512 


DENVER COLO 

R A P I D CITY SO DA K T A 


113 


GOESCH 
GOLDMAN 


G 
N 


V! I DM 

B S T N U N I V E P. S I T Y 


1 08 9 


LOS GATOS CALIF 
BOSTON MASS 




36 


GOLDSTE IN 
GOOD E 


J 

J 


H EMORY UNIVERSITY 

MH ALL I ?3UR TON COMPANY 


1 4 1 


ATLANTA G A 
DUNCAN OK LA 




1 620 
18 


GOSSETT 
GQUGH 


E 
R 


C S I NCL A I R OIL CO RP 
J I BM 




ALLENDALE NJ 

LOS ANGELES CALIF 




1 8 00 
36 


g|> 

GREEN 


W 
D 


CWAGNER ELECTRIC CORP 
VA- ARWICK ELECTRON ICS 


3 165 


BALL V I N MO 
SEPULVED A CAL IF 




1 1 30 

36 


GREENE 
. GRISELL 


R 
J 


A IBM 

LLAFAYETTE CLJN.IC „ 




END I COT T NY 
.DET.RO IT MICH „ 




3 60 

JL&Q.Q 


GROSS 
GROVE 


P 

M 


F U N I V F S A S K A T C H E V.' A N 
CI BM 




REGINA SASKATCHV/N 
SAN JOSE... CAL, IF . . 


CANADA 


1 1 30 
1800 


GU DOBS A 
HACKETT 


R 
J 


LAFAYETTE CLINIC 
EDRESSER-CLARK 


3 2 77 
12 16 


DETROIT MICH 
OLE AN N.Y. 




1 8 00 

36 


HAHN 
HALE 


D 

M 


ACORN PRODUCTS CO 

R hi U ?■ A N F A C T OR S RESCH 


3 3 85 
5 16 


PEEK IN ILLINOIS 
LOS. ANGELES CAL.IF 




1 8 00 


HALL AM 
HALL ING 


A 
B 


F F IRES TUNE T I RE 
ROLLS-ROYCE LTD 




AKRON OHIO 
DERBY ENGLAND 




3 60 
1800 


HAM IL 
HARAL AMPU 


W 
G 


R I BM-SDD 

SNEV/ ENGLAND ELEC SYS 


1 4 1 


ROCHESTER MINN 
BOSTON MASS 




1 1 30 
1 130 


HA TF I ELD 
HAYES 


F 

M 


A M C G R A W E D I S N C 
EIBM DEPT 20 6 


3 6 


ZANESVILLE OHIO 
SAN JOSE CALIF 




360 
36 


HAY A R D 
HEALE Y 


A 
P 


P DU U E S NE L I G HT C 
DI BM 


1712 


PITTSBURGH PA 
SAN JOSE CALIF- 




360 
18 


HEATH 
HENKE, JR 


V/ 
J 


D IBM 
WI BM 




MARTINEZ CALIF 
OAK PARK MICH 




1 8 00 
18 00 


HENRY 
HENS ON 


G 
R 


G IBM 

CBC GOV'T 




SAN JOSE CALIF 

V I C T R I A B C C A N A A 




1 800 
3 6 


HE RR ICK 
HERTEL 


H 

E 


L I Mi*-; ERO 

SU N I K OY AL C HEM I CAL 




NEV.' YORK CITY N.Y. 
NAUGATUCK CONN 




36 


H£*EJ INGER 

c 


V 


E I B M— DP D I V I S 1 ON 




WHITE PLAINS N.Y. 




1 1 30 








"K 







































PAGE 4 



HILL 


W 


H BEND IX CORP 


1613 


TETERBORO NJ 


— 


HIPSKIND 


J 


G C BEST OR + ASSOC 




CAR' MEL CALIF 


Ti|J • 


HO 


W 


IBM 




SAN JOSE CAL IF 


1 BOO 


HOFFMAN 


L 


LPRI NCETOM UNI VERS IT Y 


1170 


PRINCETON N.J. 


1 620 


HOWELL 


W 


EHERCULES INCORP 




WILMINGTON DEL 


3 60 


HUGHES 


R 


M INN P V.' E R + L 1 G H T 




DULUTH MINN 


3 6 


HWANG 


C 


BERKELEY SCIENTIFIC 




BERKELEY CAL IF 


1 1 30 


IND IVER I 


R 


LSINCLAIR OIL CORP 


152 5 


CHERRY HILL No Jc 


36 


IWASAK I 


S 


PALO ALTO UNFD SCH D 


52 10 


PALO ALTO CALIF 


1 620 


JOHNSON 


R 


RD M WEATHERLY CO 




ATALANTA GA 


360 


JOLLEY 


S 


MIBM 




J5AN_JJLLSE CA!,JF _ _ 


aoQ. 


JONAS 


C 


RDDW CHEMICAL CO 


34 1 7 


MIDLAND MICH 


18 00 


JONES 


C 


ETENh A+I STATE UN IV 




NASHV ILLE... TENN 


1 62 


JULIAN 


F 


BCOUNT OF SAN DIEGO 




SAN DIEGO CALIF 




KATZ 


E 


LA WATER + POWER 




DOWNEY CALIF 


3 60 


KENDRICK 


N 


BNECHES BUTANE PROD 




PORT NECHES TEXAS 


18 00 


KENNY 


A 


,q.i.^ : 




-NFV' YQRK XJTY N.X.. 




KIEL 


D 


F M I C 1 1 I G A N ST A T E U hi I V 


3 62 5 


EAST LANSING MICH 


113 


K IMG 


J 


LARK, POWER + LIGHT 




PINE BLUFF ARK 


1 1 30 


KIRKHAM 


G 


KIBM 




SAN JOSE CALIF 


18 


KLEES 


G 


NAUTONET 1 CS 




FULLEST ON CALIF 


1 6 00 


KNOELL 


D 


L B A SIC V E G E T A 1.3 L E P R D 


54 C6 


VaCAVILLE CALIF 


1130 


KOCH 


W 


J IBM 




S A N F R A N C I S C CALIF 


11 30 


K OS T E R 


D 


EMARATHON OIL CO 


53 17 


TEXAS CITY TEXAS 


1130 


KR IEGER 


J 


M I br'. 




POU G HK EE PS I E N . Y . 


3 60 


KRIEGE 


K 


BCAL POLY COLLEGE 




POMONA CALIF 


1 ljti 


KUREK 


N 


C A N G A E L E C T R N I C S 




CANOGA PARK CALIF 


c 


LACOURS I ERE 


J 


E V.' EST E R N C W T R C R P 




SIOUX CITY IOWA 


36 


LAHNERS 


F 


L V A HOSPITAL 


3 55 


OMAHA NEBRASKA 


1620 


LAMAR 


J 


RI BM 




CHICAGO I LI- 


1800 


LAND EC K 


B 


W I bfvl 




LOS ALTOS CALIF 


1 8 00 


LAND W E H R 


Ni 


F I BM 




SAN JOSE CALIF 


1 8 


LANE 


S 


E OK L A H M A U h I V E RS I T Y 




NORMAN OK LA 


360 


LANE 


w 


GCHICO STATE COLLEGE 




CHICO CALIF 


1 620 


LARUE 




HUN IV OF SO DAKOTA 




V E R M I L L I N SO DAK T A 


360 


LAWRENCE, JR 


w 


V/ I B M 




POUGHKEEPSIE NY 


1 8 


LA YNG 


V! 


L S U N D S T R A N D A V I A T I N 




ROCK FQRD ILL 


1 1 30 


LEE 


E 


SUNIV OF TORONTO 


70 1 


TOROMTO OMT CANADA 


1 62 


LEE 


J 


AUN I V OF MA SSACHUSETTS 1 1 07 


AMHERST MASS 


1 620 


LEHR 


R 


VP A N H A N D L E E A S T E f ^ N 




KANSAS CITY MO 




LENT 


R 


S IBM 




ELM IRA NeYo 


1 8 00 


LESTER 


G 


I BM 




SAN JOSE CALIF 


1130 


LEVY 


L 


N MOBIL OIL CO 




BELL INGHAM V/ ASM 


18 00 


LEW IS 


N 


J I BM 




POUGHKEEPSIE M.Y. 




LEWIS 


E 


SYLVANIA 




BUFFALO NY 


3 60 


L IN ICK 


E 


F S F T WAR E RES OU RC E S 




LOS ANGELES CALIF 


360 


L I PS ON 


A 


LVIRG.INI A ELECT + PWR. 


1 044 


R I C HM OND V A 


360 


L ITT MAN 


I 


BOISE CASCADE CORP 




BOISE IDAHO 


1 1 30 


LOMAS 


W 


A IBM 




SAN JOSE CAL IF 




LONERGAN 


P 


I B M 




WHITE PLAINS N.Y. 








'4 

.a, 
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5 


Touis 


J 


YLONG ISLAND LTG CO 


1120 


. 

H I CKSV ILLE NY 


36 


LOVE 
LUBY 


M 

w 


A IBM 

KCURN PRODUCTS CO ARGO 




CLEVELAND OHIO 

D W N E R S GROVE ILL 


1 1 30 
1 8 


LUK I NS 
LYCHE 


J 

D 


CUNIV OF KENTUCKY 
WSOCAL 


1 553 


LEXINGTON KY 
„E.L. SEGUNDO GAL IF 


18 

18 00 . 


LYNCH 
MACGREGOR 


s 

G 


A US REDUCTION CO 
TL I NF I ELD COLLE GE 


54 7 


EAST CHICAGO IND 
MC MINNVILLE ORE 


1 1 30 
1 6 2 


MALL CD Y 
M ANION 


M 

R 


CH A M B-ER L A YN E J R CL GE 
EI BM 




BOSTON MASS 
DETROIT MICHIGAN 


3 60 
1130 


MARKS 
MARM I E 


M 

F 


IBM CORP 
DBENDIX CORP 


54 2 2 


WHITE PLAINS N • Y • 

N R T hi HO L L Y V. 1 D C A L I F 


1 8 


MASK I ELL 
MASTER 


F 
J 


MMCGRAW-EDI SON 

ES 1 N CLAIR P E TR OC II E M 


3 08 1 


CANON SBURG PA 
LA PORTE TEXAS 


360 
1 8 


MATT HE ISS 
MAY- 


P 
R 


KSUN OIL CO 
VI BM 




MARCUS HOOK PA 
SAN JOSE CALIF- 


1 8 00 
1130 


MAY 
MAYER 


R 
D 


S SUNOS TR AMD A V I A T I ON 
IBM 




DENVER COLO 

YORK TOWN .NTS N,Y. 


3 60 


MC GUI RE 
MC ILVAIN 


s 


WKEN R WHITE CO 

RAIR PRODUCTS + CHEW 




DENVER COLO 
ALLEN TOWN PA 


1 1 30 

36 


MC KINNON 
MC LAUGHLIN 


G 
E 


J I BM 

EPUBLIC SERVICE CO 




ENDICOTT NoYe 
DENVER COLO 


3 60 
1800 . 


MC PAH I L . 
MC QUARRIE 


R 
C 


B G E N E R A L D Y N A r- : I C S 
AB C GOVT 




GROT ON CONN 
VICTORIA BC CANADA 


3 60 
36 


NX CALL 
C^EACHERN 


E 
N 


H I B M C 

VD EL E U V C A T hER / C A N A D A 


1 389 
7 06 8 


ST PAUL MINN 

D N M ILLS ON T CANADA 


3 60 
1130 


MC I NT Y RE 9 JR 

MEHL 


N 
J 


C CH I C S T A T E C OLL E G E 
Vi I BM 




CM ICO CALIF 

LOS GATGS CALIF 


3 60 
1 1 3 


MEIDL 

M I C HA LOW SK I 


R 
E 


A J S S C H L I T Z B R E V/ I N G 
WSYLVAN I A 


3 020 


MILWAUKEE W I SC 
TONAWANDA N»Y« 


1 1 30 

1 62 


M I SFELDT 
MOORE 


D 
V! 


DUN I TED OF OMAHA 
TUSAAVL ABS 




OMAHA NEBRASKA 
FORT EUSTIS VA 


3 60 
1 6 2 


NECESSARY 
NELSON 


J 
J 


RAVCO CORP ORDNANCE 
LI BM 


_ 


RICHMOND IND 
PALO ALTO CALIF 


3 6 
36 


NEMETH 
NORTON 


L 

w 


PHILADELPHIA WATER 
A S U T H ER N S ER V I C E S 


1125 


PHOE N I XV ILLE PA 

B I R M I N G H A M AL A B A M A 


1 1 30 

3 6 


NOW I KOV.'SK I 
• DESKY 


R 
R 


CHECK-UP INC 
I I BM 




SOU THE I ELD M ICH 
LEXINGTON KY 


1 8 00 
1 8 


OLDE 
OLDEN 


G 
L 


LUNIV OF KENTUCKY 
RGEN DYN CONVA1R 


1 553 
52 7 8 


LEXINGTON KY 
SAN DIE GO CALIF 


1 1 30 
1 8 


OLSON 
OR L OFF 


R 
M 


W IBM 

JLEAR SIEGLER INC 




CHICAGO ILL 

G R A N D RAPIDS M I C H 


3 60 
3 6 


■ORTdALS 
OSHEL 


M 
W 


H WESTERN FARMERS ELEC 
WNAVAL WEAPONS CENTER 




■ANADARKO OK LA 
CHINA LAKE CALIF 


1 1 30 
1 8 


PAGE 
PAGE 


H 
R 


L IBM 

VhWY. STATE ELECTRIC 




ENDICOTT N.Yo 
B INGHAM TON NoYe 


1 8 


PARSONS 
PAUL I N 


R 
R 


I BM 

HUNIVERSITY OF ALBERTA 




LOS GAT S CALIF- 
EDMONTON ALT A CANADA 


18 00 
1 8 


PEASE 
PEREZ 


W 
V 


A WE ST VIRGINIA P + P 
US C A S T - GE OD E T I C SDK 




CHARLESTON HTS SC 
S A N F R A N CISC C A L I F 


1 1 30 

3 6 


j^ENAAR 


L 


V F I S H RES B D C A N A D A 


7 072 


N A N A I M B C C A N A D A 


- 1 1 30 


^ . : : , . 
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P I N F I E L D 


F 


piimtv nr : <~ni n-ncn ^pkit 




V.'L^> 1 ifi.lNb ILK COLO 


1 CWV 


PODOLSK Y 


j 


1 F A T P C H T 1 P» S f - fv; T r~ f 1 1\! f "i C T 




,'"1T \/ T P W C A 1 TP 
l"l 1 V IL V.' A\l IP 




P n 1 1 F 

1 1 — 1 — l._ 


A 


J. O h: 1 K A l\ \* C- 




PA R 1 S h R Ai-JCE 


1 H 


PDI Y7DTDFS 


r- 
\j 


n h n n }<■ p p f 1-1 p iv' t c a i c n p p 




M T A C A f > A P A 1 1 C M V 
N 1 A o A K /A r ALLo N • Y « 


1 1 r v 


P n Q 7 A 

r'U K a A r\ 


i 

*L 


PI A P A V P "i" TI- f~ 1 T M T 




„Ds ' BO_IT„wi„.LCFI- 


„ LB Q„0 


POWELL 


j 


F1JWT V OF S f 1 D A K f'l T A 


> o i. o 


\/ 1- P ,v Til T n ki <^ n ha k' n t a 

V (_ t~< i k i i l_ L. Jl l_i 1 N L J I J A in I J 1 A 


o O V/ 


DD AT T 
1 \ \ r \ r 1 


p 


I nATA c r ii > p 




L' 1 A i 1 UN LI n 1 LJ 


"2 A A 

3 60 


RAFAFI I AN 


(_ 


A C n N T T MP Kl T A 1 /> \/ T PN'Tn 




n P t p ri t t ,vi t r \~\ 


J o V 


RAGS DALE 


A 


'•"•'GFNFRAI FPflDS 1 TH 


V fi c \ 

f V. ■ t ) o 


T n P f 1 Kl T D f ! Kl T (" A M A n A 

1 U I vl.ll\ i v. J t_i In 1 L M 1 •! M u n 


'■< A r\ 
p o u 


' REAMS 


H 


B W E S T E R Iv! C N T R C R P 




SIOUX C T T Y TO'.*' A 


3 6 


REESE 


r 


i_i /- i_i ir w p ("|M o p c; i..: A r j r - 1 J <T) 




P T f~ I-!a'1 Tl Mf^ C A 1 TP 
l< i v. 1 IP '• LJ In U A l_ i ! 


loUU 


RESENSTEIN 


R 


D C R Y S T A LL GR A P MY LA B 


1117 


P 1 TTS BURGH PA 


113 


R f] R F R T S 


Fj 


1 P A l\! I-I A i- 1 P> 1 P r- A c; T I "-' P M 




rS h\ IN o / \ o 1 1 T l 7 l LI 


1 o n, n 


! ROD ANTE 


F 


C T R A V E L E R S R E S E A R C H 


1 8 4 


H A R T F R D C N N 


3 6 


R S S 


p 


HI INi T V HF fv'; T t; T T PP T 




1 1 Kl T \ ' P P Q I7V f.,; T C c; 7 e c t DP T 


1 A o n 
1 O £ u 


ROSS 


T 


AUN I V OF |V. I SS I SS I PP I 




U N IV E RS I T Y M ISSISSIPPI 


3 6 


K T A IN 


w 


J U IL VK uh! Kl.iipAKLn LA) 




K 1 L. I li-i U Nl J L A\L i 1 


iB.OO, _ 


SAADAT 


fv. 


H P I N F_ E R S E R V + E N G C 




CHICAGO ILL 


36 


S A v, i ici c 

O A i * i ULLO 


L_ 


C ) 1 P IM 




Nr. 11 YU KK. L 1 1 1 N e Y 




SANDEFUR 


G 


GSCIENCE ENGKR ASSOC 




S A N 1 •■ • A R I N CALIF 


1 1 3 


S A UMDFr? S 


/\ 


F TP A V F 1 w F sf-'AP f l-i 




p a fj t P n pi^ c r\ f i m 

11 h r\ 1 1 L) r\\ J v_lJMIN 


>?po 


SAUTE'R 


J 


L I bM 




S A N J OS F C Al T F 


36 


cftJA rip 


. _ p. 


P T l- < \' 




QAM 1 r i c c r ai r P 

..,S.';VM slXiJ&j.* ...„.C £VL> LL _ 


1 i.-' n a 

_ I Q_y.O . 


SCHIFTNER 


s 


K C 1 ARKSf 'iM C \ il 1 p C-, F 




pn'rs r~> A f/- n y 

1 Oi/r\C, IN I 


3 6 


Cf Linn T T^ri-i 




P" (• ;n m s A Kl T ri 




h> 1 l.i 'U.i.ri. _.p-i u ._. 


.. . i..L>'LJ_. 






(- i_ Kj prig p p c; r v ;:r f •) I i T 




F \/ A Kl 'S T (' 1 K! Til 

L V ttl^O 1 Ul\ J.I 1 — 





S C H R AD E R 


H 


I C S CH — H A Y!*-'AR 1) 




HAY V/ A f f) C /.\ 1 T F 


SCUODFR 


j 


F- A ^ T iv'. A M K i") 1 ) A K 


J. lj O v_> 


L"> p. r U.i P-' Q T p r: ,\; Y 
r\ 1 J » — r 1 L.. O 1 CL r\ 1 \ I 




SC ULL Y 


p 


F ; ' A (-' TF) I JP M r K p l~ 




SAM FRAMrTSm f'AI TF 




SEA R S 


p 


D A FP f 'l CI) f • i A, l\i i' ~) ! -" P 




Kl f 1 P ;-i A Kl TTK 1 A 


1 f-\ O (\ 

1 O V.^ V/ 


S F P ft U S S T 


S 


p T t .; j\; — r> p c: c a l") f * H T 1" O 

1 1 l.J 1 " ■ r \ l . ■v.? i._ r-\ i \ V^, f 1 V^- 1 . \ 




YORK l"f m.'.'W FITS N « Y « 


3 P- 00 


S hi A V.' 


j 


Fib 




SAN IfiSF C Al TF 


18 


SHOE \A A K E R 


u 


S NAVAL CIV ENG L A F! 




PORT FMJENEf-iE CALIF 


162 


S I M S 


Pi 


G Ci C B EST R -)- A S S C 




CAR f-1 E L C AL 1 F 


113 


si nnnn a 


J 


Fl TNT JUNTf'JP CPI 1 F GF 




F 1 TNT iV, I C F i 


1 620 


SWART 




NH AR Z A E N G CO 


3 3 9 B 


C Fl I CA GO I LL 


113 


S M I T H 


R 


EGULF STATES UTILITY 


16 01 


3 E A U i ■ ! N T T ti X A S 


3 60 


S M T T H 


! 


H'fPTWITY I ) Kl T V F P S T T Y 

1 1 1 l\ I IN I 1 1 UIN 1 V Lr\ O 1 1 T 




SAN A K! T MM T Fl T F X A S 


36 


S M I T H 


J 


A I B f- 'i 




P li G H K E E PS I E N « Y « 


1 130 


s fv' T T F-i 

O l'i I 111 


D 
r\ 


i T R r 




fvi T n 1 A Ki 0) i\ I 1 C Fi 

I'l I Ul r\ 1 v i IJ hi. 1 L n 


1 h n n 

1 o w u 


S f/ TTH 




H 1 1 M T F f lF fv 'i T S ^ T S T P P T 




WATFP \./AI 1 F r Y M T SS 


3 60 


SMAVFI Y 




J fl P T T C A I C f 1 A T T N G 1 A \~>, 


5 4 9 


SANTA ROSA CAI TF 


113 


S U D E R S 


R 


C I B M C OR P 




CENTURY CITY CALIF 


3 60 


SPENCER 


E 


HESSO RESEARCH LABS 


113 2 


BATON ROUGE LA 


1 B 


STAFFORD 


H 


CCD M M N V; E A L T H A S S C 




JACKSON MICHIGAN 


1 1 30 


STANSBURY 


J 


C H A t._ C N I N T E R N A T I N A L 


1 1 7 8 


NEV YORK NY 


36 


STARR 


A 


T SOUTHERN PACIFIC CO 




HOUSTON TEXAS 
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pl/i and Fortran; a comparison 

part i statement s i ml lari ty 

part i i a sample program 

part ii! capabilities of pl/ ! beyond fortran 



pl/i and Fortran; a comparison 



PART 1 - STATEMENT SIMILARITY 

DATA DEFINITION 

FORTRAN 

DIMENSION A (50,50), [3(25, TOO}, C(2) 
COMMON A 

EQUIVALENCE (A, B) 
DATA c/2*1 .0/ 
INTEGERS 2 A 
REAL* 8 B 
COMPLEX D 
LOGICAL E 



DECLARE A(50 ; 50) BINARY (15,0) EXTERNAL, 

B(25 7 100) FLOAT BINARY (53) DEFINED A, 

C(2) INITIAL .0), 

D FLOAT BINARY COMPLEX, 

E BIT(l) PACKED^ 



ASSIGNMENT 

FORTRAN 

a =- b+osqrt('e) 

pl/i 

a* b+c*-sqrt(e); 



CONTROL STATEMENTS 



FORTRAN O 

GO TO 25 

GO TO (l J 3, 5j, N 

ASS I GN 3 TO N 

IF (X .EQ. Y .AND. Z .GT. Y) A-B+13 
DO 100 1-1, 15, 3 
100 CONTINUE 

PAUSE "END PHASE T 

PL/1 €> 

GO TO next; 

GO TO L 
I=3J 

IF X=Y & Z^Y THEN A=B+13j 
D100.-D0 I -1 TO 15 BY 3; 

END D100; 

DISPLAY (J END PHASE l'J J 
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INPUT OUTPUT 



FORTRAN 

READ (5,l) X,Y,Z 
FORMAT (F8 .2,2F4 l) 
WRITE (6,2) 

2 FORMAT (iHI^HEADINGS'J 
WRITE (8) X / Y J Z 
ENDFILE 8 
REWIND 8 



PL/1 



GET EDIT X,Y^Z (F 8,2), F 5..1)); 

PUT LIST ChEADINgJpAGEV 

WRITE FILE (SCRATCH) FROM (WORK) 

DCL 1 WORK 2X,2Y,2Z; 
CLOSE FILE (SCRATCH).' 



SUBPROGRAM CONSTRUCTION 



FORTRAN 

CALL MATMPY (A; B) C) 
FUNCTION SPEC (A, B) 
SUBROUTINE XTR(4,Z) 
ENTRY XTRA(Qj R) 
EXTERNAL S1,S2, S3 
RETURN (fA+B+C) 



CALL MATMPY (A, B, C); 
SPEC: PROCEDURE (A, B) \ 
XTR. e PROCEDURE (Y, 
XTRA: ENTRY (Q., R); 
DECLARE (Sly S2 7 S3) ENTRY, 
RETURN (A+B+C); 



SAMPLE PROBLEM 



QUADRATIC MODEL A Q + A T + l/ 2 A 
EXPONENT I ALLY SMOOTHED COEFFICIENTS 

READ IN DATA 

UPDATE MODEL AND MAKE NEW FORCAST 
PRINT NEW FORCAST 
PUNCH UPDATED MODEL 



PART II - COMPARISON OF SAMPLE PROGRAMS 



FORTRAN MAIN PROGRAM 



DIMENSION ID (5) 

INTEGER*- 2 ID 

COMMON OBS, PRJ? AO, A1, A2 

WRITE (6,100) 

1 00 FORMAT ^1Hl) 

1 READ (5,100 OBS, PRJ 7 AO, A1* A2, (l-.D(l), 1-1,15) 

101 FORMAT (F8.4, 4F10.4^5A2) 

CALL FORCAST ^ 
WRITE (6,102) PRJ, (l D(l), 15) 

102 FORMAT (1H F8.4 ; X1 ; I5A2) 

' WRITE (1, 103) PRJ ; AO, A1, A2 7 (ID('U, I 1 7 1 5 ) 

103 FORMAT (X8 : , 4 F10.4 ; |5A2) 
GO TO 1 

END 



c 



PL /l MAIN PROGRAM 



SAMPL: PROCEDURE OPT lONS(MAIN) J 
DECLARE (OBS jPR J jAO jA1 ^A2 ^ALPHAjBETa) 

FLOAT BINARY. ID CHARACTER (30): ) STAT I C 

EXTERNAL j 
ALPHA = .1^ BETA -.9: 
PUT EDIT PAGE} 

START: GET EDIT (OBS ; PRJ jAO 3 A1 ,A2> I d) 

• (F(8,4)., 4(x(2)j F(8.4)) ; X<2) , A(30))' j 
CALL F0RCA5T; 

PUT EDIT(pRJ 3 ID) (f(8,4) ) X(2) ) a(30) ) SKI pO) j 
PUT FILE (PUNCH) EDIT 
(PR J j AO j Ai jA2 5 ID) 

(x(8), 4(X(2) ; F(8 ) 4)) ) XC2) ;| A(30))« 3 
GO TO STARTJ 
END*. 



FORTRAN SUBPROGRAM 



SUBROUTINE FORCAST 
COMMON OBSjPRJjAOjA! y A2 
REAL#4 ALPHA /.l/ ; BETA/.9/ 
ERR^PRJ-OBS 
TEMP=A2- ALPHA**3*ERR 

A1 «* Ai +A2- 1 .5¥ALPHAW2*£2 .0- ALPHa)*ERR 

■A0«0BS+3ETA»W3^ERR 

A2-TEMP 

PRJ = A0+A1 + .5*A2. 

RETURN 

END 



pl/i subprogram 



FORCAST: PROCEDURE* 

ERR = PRJ-OBS«, 

TEMP= A2-ALPHA^3*ERRj 

A1 = A1+A2-1 .5 S *-ALPHA^2*(2- ALPHA)* ERR 

A0 = 0SS+BETA**3*ERR: 

A2*TEMPj 

PRJ = A0+A1 + .5*A2', 

RETURN *j 

END -j 



pl/i has more concise expression 
problem initialize array a and compute 

A U2 B IJ +M IMS,J FOR ALL I .J 

6 

FORTRAN 

DIMENSION A (i 00, 1 00, 1 00) 

DO 5 1=1,100 

DO 5 J=1,100 

DO 5 K*1, 100 
5 A (l. J^sO.O 

DO 10 1=1 100 

DO 10 Jsl 100 
10 A(l,J,2)-B (l,j)+M (l,MS(6) ; j) 

PL/l 

DCL A (l 00 ,100,100); A-Oj 
A (*, ¥, 2)r B+M (*> MS( 6 ), *)j 



pl/i has 

PROBLEM 



BETTER INTERRUPT CONTROL 



ALLOW FLOATING POINT UNDERFLOW FIRST 
1 00 TINES THEN KILL JOB. 



FORTRAN REQUIRES ASSEMBLY LANGUAGE ROUTINE. 



ON UNDERFLOW BEGIN j 

DCL COUNT FIXED V '3) INIT(o)^ 

IF COUNT = 99 THEN DOj 

PUT LI ST ('100 UNDERFLOWS') SKIPf 

SiGNAL FINISH} END j 

COUNT =C0UNT+1 ^ 

RETURN: END! 



PL/1 HAS MORE EXTENSIVE- DATA EDITING 



SOURCE 


TARGET 


UUIUU 


1 Uu 


10203 


12 3 


1234.56 


1.234.56 


12 


1 2 


001.23 


$1 .23 


-123 


$1 .23CR 




+ 


1 23 


123 


-123 


123 



4>Z. 



pl/i has superior array handling 
examples 

DECLARE a(-5:-25 3 17:18) J 
DO l=-5 TO -25 BY -5 } 
- 25 TO - 30 BY - ] y 
WHILE ( X=19.6)*j 
A=B+C/E3 

WHERE AjBjCjAND E ARE 
ALL N- DIMENSIONAL ARRAY! 



Pl/l HAS MORE BUILT IN FUNCTIONS 



EXAMPLES 

DATE RETURNS CHARACTER STRING YYMMDD 

TIME RETURNS CHARACTER STRING HHMMSSTTT 

SUM(x) RETURNS SUM OF ALL ELEMENTS OF X 

PROD(X) RETURNS PRODUCT OF ALL ELEMENTS OF X 



PL/1 HAS CHARACTER STRING AND BIT STRING PROCESSING 
EXAMPLES 

DCL SYMPTOMS BIT (64-) PACKED ^ 
HEADACHE BIt(i) DEFINED SYMPTOMS 
POSITION^) ; 

FEVER BIT(l) DEFINED SYMPTOMS 
POSITION^} 

IF HEADACHE^ FEVER THEN GO TO ASPIRIN} 
ELSE GO TO PENECILLIN3 

BIT(64) REQUIRES 8 BYTES OF STORAGE 
X='XYCOMABCMON l j 

Y= INDEX^Xj'COM'}, 
Zss INDEX (Xj 1 N,ON'Jj 
A-^SUBSTRfx^Y^)! j SUoSTRCx^ZjS) j 



A WILL BE SET TO COMMON 



IN ADDITION PL/l OFFERS 

COMPILE T I ME CAPABILITY (MACROS") 
LIST PROCESSING 
MULT I -TASKING 

DYNAMIC ALLOCATION AND RELEASE OF STORAGE 
EXTENSIVE DEBUGGING 
EXTENSIVE l/o CAPABILITY 
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DYNAMIC MODEL SIMULATOR FOR THE IBM 1 1 30 

by 

George D. Polyzoides 
Hooker Chemical Corporation, Niagara Falls, New York 



The Dynamic Model Simulator is a chain of FORTRAN source programs 
that permits the IBM 1 1 30 user to investigate in depth the dynamic behavior 
of physical systems that can be modeled into linear or nonlinear ordinary 
differential equations. 

It can be used for the investigation of a wide range of engineering 
and mathematical problems from reaction kinetics and reactor responses to the 
design of electrical networks and structural assemblies. 

The system does not require familiarity with analog computers al- 
though in a way it forces the IBM 1 1 30 hardware to perform the function of 
an analog computer while at the same time it offers the digital computer ad- 
vantages of random memory access and ten digit (extended) precision. 

The input consists of English command words (START, WAIT, RESET, etc.) 
and numeric data which are re-.. d in free format. 

The system output includes tabulated values of the variables at 
specified intervals, a table of the variables involved and detailed error and 
information messages. Plotting of the variables is also available as an option. 



System Source Language: FORTRAN IV, Level E 

System Hardware Requirements: 1131 CPU-8K, one 2315 disk cartridge 

M\U2 Card Reader 
1132 Printer 

Benson- Lehner 305 Digital Incremental Plotter 

(opti onal ) 



DYNAMIC MODEL SIMULATOR 



FOR 



THE IBM 1130 SYSTEM 



George D. Polyzoides 
Hooker Chemical Corporation 
December 1967 
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NIAGARA FALLS, NEW YORK 14 3 02, PHONE (716) 2 8 5 -6 6 5 5 

ABSTRACT 

The Dynamic Model Simulator (DYNAMO) consists of a series of 
FORTRAN IV programs that allow the IBM 1130 user to investigate with 
detail and accuracy the behavior of physical systems that can be modeled 
into linear or nonlinear ordinary differential equations* 

The DYNAMO Simulator can be of great help to engineers and 
scientists who consider such time consuming problems as the investigation 
of the transient behavior of chemical reaction systems, electrical networks, 
process variables and control systems. 

The Input to the DYNAMO Simulator is in free format and in the 
form of distinct key words and numbers. The digital computer setup 
prohibits real time operation but it offers the additional advantages of 
accuracy, data storage and detailed plotting. Besides the input-output 
and calculation mainlines DYNAMO utilizes the 1130 Plotting System, a 
plotting software package created by Hooker *s Systems Engineering Group. 

The minimum equipment requirements for program execution arex 
1131-CPU-8K-2B 

1442 Card Reader and 1132 Printer 

The Plots (optional) can be obtained through an on line digital 
plotter (.005"/step). 
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INTRODUCTION 

The expansion of the range of the applications of digital 
computers into fields that were the traditional domain of analog 
computers is a rather recent trend that has produced such interesting 
results as the GPSS, the CONSIM, the CSMP, the PACTOLUS and other 
simulation systems. The DYNAMO Simulator does not claim "a place in 
the sun" among these systems. Its mode of operations is more restricted 
and less sophisticated. The object of DYNAMO is the solution of ordinary 
differential equations and the emphasis is on the mathematics rather than 
the block diagrams. Since differential equations and block diagrams are 
frequently equivalent in describing a system, it follows that in many 
instances DYNAMO can be used in obtaining results similar to the ones 
obtained from larger and more complicated systems. 

The point o"f decision when programming for analog to digital 
equivalences is whether analog procedures and nomenclatures should be 
carried over to the digital system's specifications. For example, should 
gain be labeled as such, or should it be implied by a multiplication? One 
can argue about the advantages and the nuisances of both types of approach. 

The DYNAMO Simulator approaches the problem from the point of 
view of the person who has more experience in digital than in analog 
computation* This implies that analog computer nomenclature, wiring 
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diagrams, and scaling are not necessary to describe and set up the 
problem. The analog concepts, although still present and helpful, 
tend to fall in the background while rami! iarii^ with digital concepts 
becomes essential • 
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PART ONE 

PROGRAM CHARACTERISTICS 

A) INPUT REQUIREMENTS 

The input to the DYNAMO Simulator consists of some key words 
and numeric data. The programs have been written in such a way as to 
permit experimentation with the differential equations that describe the 
model. The execution of the programs can be interrupted at five distinct 
points and restarted at some later time without loss of continuity. 

1* Input Language 
The key input words or commands constitute a very elementary input 
language. The term "language" is applicable only as far as it is under- 
stood as the substitution of a numeric code with English words. The 
input commands can be divided into six categories : 

i) Integration Information commands: They define the step length 
and interval of the integration, value of the equation coefficients, etc.) 
CONTROL, COEF 

ii) Identification command si TITLE, TABLE 

iii) Initial conditions commands: START, RESET, REPEAT, RESTART 
iv) Utility commands: SETUP, LOG, NOLOG 
v) End Indicator commands: WAIT, END, HALT 
vi) Output commands: PLOT (see Appendix B) , LIST, FILE 
For those interested in more details the DYNAMO input language is presented 
in more length in Appendix A. 
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2. Input Procedures 

The DYNAMO commands and the required numeric data can be entered through 
punched cards or the 1131 console. The two Input modes can be alternated 
during program execution* All commands are listed on the 1131 console, 
but listing can be stopped upon use of the NOLOG command . The SETUP command 
can be used to reset the system standard files (see Appendix D). 

All commands and data are entered on a free format basis* The 
special plotting Instructions are only sequence dependent* More will be 
said about free format in subsequent sections • 

Upon detection of F- type input errors in the numeric data or an 
erroneous command the user has the option of causing a "PAUSE" and correcting 
the error* More serious logic errors (i*e* no initial conditions specification) 
cause exits to the monitor* The files containing the standards for the system 
are not closed and most of the times the error can be corrected and the run 
can be restarted without loss of continuity* 

3. The Mathematical Model 

All the first order ordinary differential equations describing the model 
must be previously stored as a function subprogram* The present dimensioning 
allocations allow a maximum of twenty variables (equations). 

These ordinary differential equations may be linear or nonlinear* 
Second or higher order equations can be expressed as two or more equivalent 
first order equations* The coefficients of the equation terms can be 
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variable and their values must be present during the input step. 

The DYNAMO Simulator will accept any first order differential 
which can be arranged in the form:* 



where Yi is the i^ h dependent variable and x is the independent variable 
EXAMPLE 1 

Algebraic expression: ^£ + > 0*Y2 = SlNX*. SYi 
DYNAMO FORTRAN: Fs SIN(X) - • 0»*Y(2 i L') + . 9*Y(i,i) 

The value of L is determined in the calling mainline. The 
function subprogram must contain a computed GO TO statement so that the 
appropriate derivative value for each variable is selected. Appendix C 
contains sample subprograms in both algebraic and FORTRAN notations. 



* Other equation forms can be expressed in the form of equation - 
after some mathematical manipulation. 
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B) PROGRAMMING TECHNIQUES 

The present version of the program consists of two input mainlines, 
an error checking mainline, the mainline that solves the differential equations 
and the mainline that generates the plotting specifications. The actual 
plotting is accomplished through a separate software package. Due to the 
number of CALL LINK** that is involved the majority of the programs have been 
stored in core image to allow for fast loading. 

1. System Standards 

A seventy (70) digit integer vector is initialized and then continuously 
updated and maintained through each execution of the DYNAMO programs. 
Appendix D contains a list of the information contained in the vector. The 
standards can be reset by using a special "standards generation" program or 
by using the SETUP command during the program execution. 

2. The Predictor-Corrector method for numerical integration. 
The solution of the differential equations describing the model is the 
most vital part of DYNAMO. The Predictor-Corrector method of Hamming(l) 
has been found to fulfill the important considerations of stability, 
accuracy and relative calculation speed. 

No attempt will be made here to discuss the method in detail. 
Any such effort would be a reproduction of the excellent article by 
Ralston(2) describing the details. The limited information to be presented 
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in this paper is here just for clarifying the overall approach. 

Given the values of M dependent variables (Y) and an independent 
variable (X) at four equiapaced points in the X domain (0, 1, 2, 3) the 
predictor corrector method (fifth order accuracy) is a means for obtaining 
the M values of (Y) at point (4). This procedure can be generalized by 
setting the four known points of the domain aa n-3, n-2, n-1, and n and by 
considering the points to be obtained as the x domain value becomes Xhtl. A 
set of four equations is used for each i tn variable (i=l,M) and this 
procedure will repeated until reaches a present value: 

i) The predictor equation gives a rough estimate of Y(i,n+1) 

ii) The modifier and corrector equations eliminate the need for iterative 
convergence : 

where(j» n -t'« > ) is the truncation error from the last step^ ^ *s Vl»* Jerm*hr« & 
III) The final equation takes the formt 

where^^- C n+ ,^is the present truncation step. 

Prom the point of view of calculations the only additional 
requirement is that the values for Y( V ,K), where (K=2,4) must be calculated 
from the initial conditions Y( V ,1) before equations (2-5) can be executed. 
This initial step, commonly called the STARTER consists of a first order 
Newtonian extrapolation and an iterative convergence technique described in (2). 



hooker 



10 



Stability checks have been incorporated in the integration routines* 
The user can check the stability of the calculations by using DATA SWITCH 4 
during the execution of the program. 

3* Data conversion from extended to standard precision. 
In order to minimize the accumulation of the inherent roundoff errors, the 
DYNAMO mainlines (with the exception of the plot generation mainline) have 
been compiled in extended precision. The 1130 Plotting System is composed 
of standard precision mainlines. The DYNAMO data must be converted into 
standard precision before they are stored in the files from where the plotting 
mainlines are to pick them up. 

Conversion is accomplished by equivalencing the extended precision 
floating point values of X and Y(i,k) to a three digit vector J and by creating 
the new integers IY(20,2) and IX(20). The technique can be outlined as 
follows x 

i) Equivalence i 



I 





S MANTISSA 






T(2) 




= J(2) 

= (J(l)/256)*2 


56 



47 



VECTOR J 



MANTISSA ^ 



iv) ITCi.l) = IY(i,l) + J(3) 







It li 





v) store IY(i,l) and IY(i,2) 



5 




(has Acrt- 


iVCZ) l tVCA) 



The 32 bits comprising the last figure will be treated as a floating point 
variable Y(i,k) when read from the permanent file by a standard precision 
program. 
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4. The free format routines 
The free format Input Is accomplished by a group of subroutines that perform 
the following operations, after a data card has been read in (80A1 Format) 
and a starting and ending column number has been indicated: 
1) Detection of the first nonblank character* 
ii) Detection of a predetermined (EBCDIC) character code, 
iii) Retrieval of an integer number, 
iv) Retrieval of a floating point number, 
v) Retrieval of an alphameric text contained between two apostrophi. 

As an example of the utilization of these subroutines consider the data 
card shown below: 



olumn . T a i 

io 18.6 TV 2 4 

1 2345678911111111112 222222222 

01234567890123456789 



i) set starting column (1) and detect the first nonblank (5). 
ii) Find first blank column after (5) (column 7). 
iii) Use integer retrieval routine (columns 5-6). 
iv) Starting with column 7 find nonblank character (11 )• 
v) Find next blank (15) and retrieve floating point number (11-14). 
vi) Search for T and if search Is successful (as It will be) retrieve 
the number following the (=) sign. 
5. The Digital plotting 
All plotting must be done on a .005"/step digital plotter. By interpretting 
the special Instructions (Appendix B), the program generates the plotting 
specifications. These specifications are then stored in a file, the plotter 
programs are loaded in core, the plotting specifications are read In from 
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the file and the plots are produced. The DYNAMO user may exercise 
a variety of options in generating the plot specifications! 

i) The right-hand Y axis can be used independently of the left hand 
Y-axis or it may be omitted completely* 
11) Titles may be specified for the plots and the plot axes. 
Hi) Two of the following three quantities may be present or all three 
may be determined by the plotter scaling routines. 

a) . axis minima 

b) axis maxima 

c) axis "delta" increment (units/inch) 

iv) The data can be plotted as points, least squares lines, or points 

with fill-in lines, 
v) The X-Y variables can be transformed (Y2-*Y2A1*Y3) 
vi) The size of any of the axes to be used may be either 7. or 10. 
without the frame or 8. 5" or 11". with the frame, 
vii) An additional axis, same as the parallel to the X axis may be 

specified so that the axes enclose the graph in a rectangular box. 
viii) Undesirable Y variables may be omitted and the x- axis variables 
for the plot may be any of the X-Y variables, 
ix) The X (or Y) axis may be shifted to the zero point of the Y (or X) 
axis . 

x) The data for the plots may be generated from values stored between 
any two records of the file (max. 50 records/plot). 
Plotting of the results from the simulation can be postponed for 
some other time by INTERRUPTING the program after the data are calculated, 
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printed and stored. An examination of the listed output may suggest patterns 
for a more meaningful graphical presentation of the data. The punched output 
is in a format directly acceptable to the stepwise regression program of the 
Hooker library. In this way the results from the DYNAM) Simulator can be used 
to form algebraic equations describing the variables* This can be a great 
time saving feature when the mode! under investigation is part of a bigger 
model • 

6. Future Expansions 
The present form of DYNAMO can become a more versatile computational tool 
with the addition of a function generator and a way to specify disturbances 
directly. (Distrubances can be investigated now in an indirect manner). 

From the viewpoint of calculation speed two more steps are to be 
considered for future improvements: 

a) Introduction of a variable step length. 

b) Use of an assembly language "patch" to speed up the numerical 
integration. 
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PART TWO 

EXAMPLES OF APPLICATIONS 

CASE No. 1 A CSTR Battery (4) 

We will investigate the changes of concentration of a component 
A when a second order reaction A »B takes place in a two stage CSTR 
battery. The diagram below shows the flow pattern and the equipment layout: 




The mass balance equations around the tanks aret 

i) first tankt ±(y{) + ¥i «. K t VI* = Co 

eft e « 

ii) second tankt jl^y?) + ^2 + - ^ 
where: @ is the retention time 

= the reaction rate constant 
VI ,7,2 = the concentrations of A in tanks 1 & 2 respectively. 
The following pages illustrate a) the use of the DYNAMO language in the 
input phase b) the standard printed output and c) a sample of plotter output. 



14a 



c 



TITLE 

TWO CSTR BATTERY -SECOND ORDER REACTION 
CONTROL 6 

1 2 

2 2*4 

3 .01 

4 1 

5 10 

6 1 
START 
0. 

1. 
1* 

LIST 10 
PLOT 1 

NUMBER = 1 T I TLfc • CSTR BATTERY//TANK 1 SOLID LI NE/ /TANK 2 DOTTED LINE' 
X AXIS TYPE = 12 TITLE'ELAPSED TIME IN MINUTES' 
VARIABLES 
FILE NO. = 1 



YLLFT AXIS TYPE = 12 TITLE 1 MOLE FRACTION OF COMPONENT A IN TANK * 
VARIABLES 

FILE NO. 2= LINE=1000 GRAPH=4222 
FILE N0.3- LINE-2510 GRAPH=4322 



* 



1 

2 
3 
4 
5 
6 
7 
8 
9 

10 
11 



GENERAL OPTIONS 

FRAME 

STOP 

TABLE 

THE FOLLOWING RESULTS INDICATE THE CHANGES IN THE 
CONCENTRATION OF A COMPONENT (A) UNDERGOING A SECOND 
ORDER REACTION (K = .5 ) IN A TWO 

CSTR BATTERY. 

FIRST VARIABLE TIME IN MINUTES 

SECOND VARIABLE CONCENTRATION OF A I N TANK 1 

THIRD VARIABLE CONCENTRATION OF A IN TANK 2 

THE INITIAL CONDITIONS ARE 

TIME 0. A IN TANK 1 AND 2 100 PERCENT 

THE RETENTION TIME (THtTA) IS ONE MINUTE 

CONCENTRATION OF INPUT STREAM IS 100 PERCENT 



END OF RUN 




$3 , 



TWO CSTR BATTERY -SECOND ORDER REACTION 
DYNAMO INFORMATION TABLE 

THE FOLLOWING RESULTS INDICATE THE CHANGES IN THE 
CONCENTRATION OF A COMPONENT (A) UNDERGOING A SECOND 
ORDER REACTION <K=.5 ) IN A TWO 

CSTR BATTERY. 

FIRST VARIABLE TIME IN MINUTES 

SECOND VARIABLE CONCENTRATION OF A IN TANK 1 

THIRD VARIABLE CONCENTRATION OF A IN TANK 2 

THE INITIAL CONDITIONS ARE 

TIME 0. A IN TANK 1 AND 2 100 PERCENT 

THE RETENTION TIME UHETA) IS ONE MINUTE 

CONCENTRATION OF INPUT STREAM IS 100 PERCENT 



TWO CSTR BATTERY -SECOND OROEK REACTION 
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V lRST COLUMN- INDEPENDENT VAR I ABLE < X ) • DEPENDENT VARI ABLES I Y ) FOLLOW SI* P£R ROW 



O.OOuOOE ou 



O.lUUUUE 01 0.10000E 01 



10 0.10U00E 00 



0.95464E 00 0.95245E 00 



20 0.20000E 00 



0.91735E 00 0.90961E 00 



30 0-30U00E 00" 



0.88656E 00 0.87114E 00 



40 0.40UU0E OU 



0.86108E 00 0.83669E 00 



50 0.50000E 00 

60 0.59999E 00 

70 0.69999E 00 

80 0.79999E 00 



0.83992E 00 0.80590E 00 



0.82231E 00 0.77843E 00 



0.80765E 00 G.75397E 00 



0.79540E 00 0.73222E 00 



90 0.89999E 00 



0.78517E 00 0.71291E 00 



100 0.99999E 00 



0.77661E 00 0.69577E 00 



110 0«10999E 01 



0.76945E 00 0.68059E 00 



120 0.11999E 01 



0.76345E 00 • 0.66716E 00 



130 0.12999E 01 



0.75842E 00 0.65528E 00 



140 0.13999E 01 



150 0.14999E 01 



160 0.15999E 01 



0.75419E 00 0.64479E 00 



0.75065E 00 0.63554E 00 



0.74768E 00 0.62738E 00 



TWO CSTR BATTERY -SECOND ORDER REACTION 
FIRST COLUMN- INDEPENDENT VAR I ABLE ( X ) • DEPENDENT VAR I ABLES ( Y ) FOLLOW SIX PER ROW 



o 



170 0.16999E 01 



0.74518E 00 0.62020E 00 



180 0.17999E 01 



0.74309E 00 0.61388E 00 



190 0.18999E 01 



0.74133E 00 0.60832E 00 



200 0.19999E 01 



0.73985E 00 0.60344E 00 



210 0.20999E 01 



0.73861E 00 0.59916E 00 



220 0.21999E 01 



0.73756E 00 0.59541E 00 



230 0*22999E 01 



240 0.23999E 01 



0.73668E 00 0.59212E 00 



0.73594E 00 0.58924E 00 



^J 1 
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CASE Ncu 2 



Design of an RLC circuit (5) 



© 



The investigation of the transient behavior of electrical networks 
is another potential area of applications. The signle loop RLC circuit pictured 
below is a textbook example of differential equation solving* The diff, 
equations describing the transient characteristics of the circuit aret 



Current: J^i C 
Voltage (across the capacitor): 



where: i = current amp 

L = inductance henry 

C - capacitance farad 

R - resistance ohm 

E = potential volts 
v - voltage " 



\ 4 

C lost O 



C lost 



The behavior of such a circuit will be investigated for three cases t 
a) overdamping b) critical damping c) underdamping. This will be 
accomplished by using the COEF command to set appropriate values for R, L, 
and C» The REPEAT command will cause continuous execution with the original 
initial conditions ♦ The next pages show the input requirements and the 
resulting output (the plotting instructions have been omitted for the sake 
of brevity). 
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TITLE 

RLC CIRCUIT CALCULATIONS-OVERDAMPED CASt 
TABLE 

THE INITIAL CONDITIONS FOR THE RUN ARE 

A) I<0)=0 

B) V(0)=Q 

C) <DU>/DT).0 = <E-VCO)/L = 4 

E) THE CIRCUIT POTENTIAL IS 4 VOLTS 
VARIABLE COEFFICIENTS 

NUMBER 1 RESISTANCE 
.NUMBER 2 CAPACITANCE 
NUMBER 3 INDUCTANCE 



OUTPUT 
TIME IN 
CURRENT 
VOLTAGE 



SECONDS - FIRST COLUMN 

IN CIRCUIT - THIRD COLUMN 

ACROSS CAPACITOR - FOURTH COLUMN 



COEF 




1 


3.0 


2 


1.0 


3 


1.0 


CONTROL 


6 


1 


3 


2 10. 




3 .001 




4 


1 



5 
6 



LIST 



5TART 
0. 
4. 
0. 

0. 

1000 
WAIT 
TITLE 

RLC CIRCUIT CALCULAT IONS-CR I TICALLY DAMPED CASE 

REPEAT 1 

TABLE 

SAME INITIAL CONDITIONS AS PREVIOUS RUN 



CONTROL 1 
8.0 

COEF 

1 2.0 

LIST 1000 
WAIT 
TITLE 

RLC CIRCUIT CALCULATIONS-UNDERDAMPED CASE 
REPEAT 1 
CONTROL 1 



TABLE 

SAME INITIAL CONDITIONS AS BEFORE 

15 b 

COEF r\ 

i i • o 

LIST 100 
END 



RLC CIRCUIT CALCULAT IONS-OVERDAMPED CASE 

DYNAMO INFORMATION TABLE * 

15 C 

THE INITIAL CONDITIONS FOR THE RUN ARE 

A) I(0)*0 

B) V(0)*0 

C> (DU)/DT).0 = (E-VCOJ/L = 4 
E) THE CIRCUIT POTENTIAL IS 4 VOLTS 
VARIABLE COEFFICIENTS 

NUMBER 1 RESISTANCE 
NUMBER 2 CAPACITANCE 
NUMBER 3 INDUCTANCE 

OUTPUT 

TIME IN SECONDS - FIRST COLUMN 
CURRENT IN CIRCUIT - THIRD COLUMN 
VOLTAGE ACROSS CAPACITOR - FOURTH COLUMN 
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RLC CIRCUIT CALCULAT IONS-OVERDAMPED CASE 
LIST OF ENTERED COEFFICIENTS 



2 



15 D 



COEF. NO. 1 
COEF. NO. 2 
COEF. NO. 3 



THE VALUE IS 
THE VALUE IS 
THE VALUE IS 



0.30UOOE Ul 
0.10000E 01 
0.10000E 01 



22- 
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RLC CIRCUIT CALCULAT10NS-0VERDAMPED CASE 15 E 

IRST COLUMN- INDEPENDENT V AR I ABLE ( X ) • DEPENDENT VARIABLES ( Y ) FOLLOW SIX PER ROW 



O.OOOOOE 00 



0.40000E 01 O.OOOOOE 00 O.OOOOOE 00 



100O 0.99999E 00 



-0.12472E 00 0.10904E 01 0.85341E 00 



2000 0.19999E 01 



-0.29337E 00 0.82378E 00 0.18220E 01 



3000 0.29999E 01 



-0.21542E 00 0.56805E 00 Q.25112E 01 



4000 0.39999E 01 



-0.14813E 00 0.38813E 00 0.29837E 01 



5000 0.49999E 01 



-0.10118E 00 0.26493E 00 0.33063E 01 



6000 0.59999E 01 



-0.69069E-01 0.18082E 00 Q.35266E 01 



7000 0.69999E 01 



o 



8000 0.79999E 01 



-0.47141E-01 0.12341E 00 0.36769E 01 



-0.32174E-01 0.84235E-01 0.37794t 01 



9000 0.89999E 01 



-0.21960E-01 0.57492E-01 Q.38495E 01 
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-Rt€~~ei^tfiT CALCULATiONS-CRIT ICALLY DAMPED CASE ~— " 
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OYNAMO INFORMATION TABLE 
SAME~ffiif I At CONDITIONS AS PREVIOUS RUN ~ ^ 



o 
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RLC CIRCUIT CALCULAT I ONS-CR I T I CALL Y DAMPED CASE 



LIST OF ENTERED COEFFICIENTS 

0.2U000E Ul 
0.10000E 01 
0.10000E Ul 



COEF. NO. 1 THE VALUE IS 

COEF. NO. 2 THE VALUE IS 

COEF. NO. 3 THE VALUE IS 



7 

RLC CIRCUIT CALCULAT I ONS-CK I T I CALL Y DAMPED CASE 15 H 

FIRST COLUMN- INDEPENDENT VAR I ABLE ( X ) • DEPENDENT VARIABLES ( Y ) FULLUW SIX PER R 



O.OOOOOE Ou 



U.40000E 01 O.OOOOOE 00 O.OuGOOE 00 



1000 0.99999E 00 



0.23819E-06 0.14715E 01 0.10569E 01 



2000 0.19999E 01 



-0.54134E 00 0.10826E 01 0.23759E 01 



3000 0.29999E 01 



-0.39829E 00 0.59744E 00 0.32034E 01 



4000 0.39999E 01 



-0#21978E 00 0.29305E 00 Q.36336E 01 



5000 0.49999E 01 



-0.10780E 00 0.13475E 00 0.38383E 01 



6000 0.59999E 01 



■0.49575E-01 0.59490E-01 0.39306E 01 



7000 0.69999E 01 



8000 0.79999E 01 



-0.21885E-01 0.25532E-01 0.39708E 01 



-0.93930E-02 0.10734E-01 0.39879E 01 
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RLC CIRCUIT CALCULAT IONS-UNDERDAMPED CASE 
DYNAMO INFORMATION TABLE 

£AM£ INITIAL CONDITIONS AS BEFORE 



RLC CIRCUIT CALCULAT IONS-UNDERDAMPED CASE 
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15 J 



LIST OF ENTERED COEFFICIENTS 

COEF. NO. 1 THE VALUE IS O.IOOOOE 01 

COEF. NO. 2 THE VALUE IS O.IOOOOE 01 

COEF. NO. 3 THE VALUE IS O.IOOOOE 01 
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RLC CIRCUIT CALCULATIONS-UNDfcRDAMPED CASE 
FIRST COLUMN- INDEPENDENT VARIABLt(X). DEPENDENT V AR I ABLES ( Y ) FOLLOW SIX PER ROW 



10 
15 



O.OOOOOE OU 



0.40000E 01 O.OOOOOE 00 O.OOOOOE 00 



100 0.99999E-01 



0.36006E 01 O.38001E 00 0.19333E-01 



200 0.19999E 00 



0.32050E 01 0.72025E 00 0.74676E-01 



300 0.29999E 00 



0.28166E 01 0.10212E 01 0.16207E 00 



400 0.39999E 00 



0.24384E 01 0.12839E 01 0.27765E 00 



500 0.49999E OU 



0.20729E 01 0.15Q93E 01 0.41762E 00 



600 0.59999E 00 



0.17226E 01 0.16990E 01 0.57833E 00 



{*) ™0 0.69999E 00 0.13892E 01 0.18544E 01 0.7i>628E 00 



800 0.79999E 00 



0.10743E 01 U.19774E 01 0.94814E 00 



900 Q.89999E 00 



0.77922E 00 0.2O70OE 01 0.11507E 01 



1000 0.99999E 00 



0.50477E 00 0.21340E 01 0.13612E 01 



1100 0.10999E 01 



0.25163E 00 0.21716E 01 0.15766E 01 



1200 0.11999E 01 



0.20195E-01 0.21850E 01 0.17947E 01 



1300 0.12999E 01 -0.18941E 00 0.21764E 01 0.20129E 01 

1400 0.13999E 01 -0.37727E 00 0.21479E 01 0.22293E 01 

1500 0.14999E 01 -0.54366E 00 0.21017E 01 0.24419E 01 

1600 0.15999E 01 -0.68905E 00 0.20398E 01 0.26491E 01 
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RLC CIRCUIT CALCULAT I QNS-UNDERDAMPED CASE 
FIRST COLUMN- INDEPENDENT VAR I ABLE ( X ) • DEPENDENT VAR I ABLE S ( Y ) FOLLOW SIX PER ROW 



10200 0.10199E 02 



-0.28095E-01 0.15698E-01 0.40124E 01 



10300 0.10299E 02 



-0.26781E-01 0.12952E-01 0.40138E 01 



10400 0«10399E 02 



-0.25338E-01 0.10345E-01 0.40150E 01 



10500 0.10499E 02 



-U.23791E-01 0.78887E-02 0.40159E 01 



10600 0.10599E 02 



-Q.22165E-01 0.559O2E-02 0.40166E 01 



10700 0.1Q699E 02 



-0.20484E-01 0.34573E-02 0.40170E 01 



10800 0.10799E 02 



-0,18767E-01 0.14946E-02 0.40173E 01 



10900 0.10899E 02 



-0.17035E-01 -0.29559E-Q3 0.40173E 01 



c 

/do. 
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Rl_C CIRCUIT ANALYSIS 
UNOERDAMPED CASE 
CURRENT XXXX 
Vfl TARF 
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L « 
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ELAPSED TIME IN SECONDS 
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DYNAMO INPUT LANGUAGE 
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The following is a list of the DYNAMO input commands and the 
functions they initiate during the program execution: 

A) INTEGRATION and STORAGE control: 
CONTROL M 

This command causes the program to accept M data cards. These cards 
may be used to define: a) The number of equations describing the system, 
b) The integration increment (delta), c) The total integration domain, 
d) The initial conditions files to be used, e) The frequency for 
storing the integration data on the disk, and f) The disk record where 
the first X-Y data are to be stored, 
COEF 

This command permits the entering of the values for the variable coefficients 
of the differential equations. 

B) INITIAL CONDITIONS control: 
START 

This command permits the entering of the initial conditions for the first 
step of the calculations, 
REPEAT M 

The program will return M-l steps back and it will begin calculations with 
the initial conditions of this step. 
RESTART M 

Depending on the value of number M an interrupted run can be restarted at 
different points. 
RESET 

The last X-Y record of the previous run is used as the initial conditions 
of this run» Other integration variables can be changed through the CONTROL 
command « 

/c 
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C) IDENTIFICATION control 1 
TITLE 

The contents of the card following the TITLE card will be printed as a 
heading to all output pages, 
TABLE 

A maximum of twenty cards with information pertinent to the input data or the 
model can be read and stored with this command. This information Is later 
printed on the 1132 Printer. 

D) OUTPUT control: 
LIST M 

The calculated results from every M tn integration step will appear on the 
1132 Printer. 

PLOT M 

This command specifies that M sets of plotting instructions follow. 

FILE OP = n START = m END = k 
This command indicates some operation on the data files, depending on the 
value of the OP code, (storing, listing, punching). M and K Indicate the 
starting and ending records for listing or punching only. When OP Is 
negative no calculations need preceed the file Operation. The number of 
variables to be dumped or listed is controlled by the CONTROL command. 

E) UTILITY commands: 
SETUP: 

This command resets the standards files during program execution. 
LOG, NOLOG 

These commands control the listing of the Input data on the 1131 console. 
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F) END INDICATORS 
WAIT 

Stop input and proceed with execution* Return for more data. 
HALT 

Stop input and pause, teien the START button is pressed resume execution of 
the input* 
END 

Stop input and proceed with execution. Return to monitor. 



JO 
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APPENDIX B 
PLOTTING INSTRUCTIONS 



THE CARDS FOLLOWING THE •• PLOT M COMMAND 
CONSTITUTE A SIMPLIFIED APPROACH TO DIGITAL PLOTTING. A SET OF PLOTTING 
SPECIFICATIONS»SIMILAR TO THE ONES LISTED BELOW MUST BE PRESENT 
FOR EVERY ONE OF THE M PLOTS SPECIFIED. 



PLOT 2 *** DYNAMO COMMAND**** 
NUMBER = X T I TLE * PLOT NO. • 1 • 

X AXIS TYPE * 12 TITLE 1 INCHES OF WATER • MIN ■ .001 MAX = 
SHIFT = 
VARIABLES 
FILE NO. =1 



** 



Y LEFT AXIS TYPE=12 TITLE* VOLUME OF WATER IN LITERS' 
VARIABLES 

FILE NO. * 2 LINE = 1000 GRAPH * 4122 CODE * 4251 
TAG • DIAMETER 2 FEET* 

FILE NO. = 3 LINE = 2511 GRAPH = 4122 CODE = 4281 
TAG* DIAMETER 3 FEET* 



GENERAL ** INSTRUCTION TO PERMIT ENTERING GENERAL SPECS** 

PARALLEL X 

FRAME 

STOP 

NUMBER = 2 TITLE 1 SECOND PLOT 1 



... 



STOP 



*• OTHER DYNAMO 



COMMANDS 



** 



THE PLOTTING INSTUCTIONS ARE USED TO DEFINE THE PLOT TITLEtTHE 
TYPE OF THE AXES< LI NEAR .LOGARI THMIC »POLAR )»THE SIZE OF THE AXES( 8.5 OR 

/OP 



11 INCHES) AND THEIR MAXIMUM OR MINIMUM LIMITS IF IT IS SO DESIRED. 
INPUT FOR DIFFERENT AXES IS SEPARATED BY <*> AND THE END OF ALL INPUT 
FOR THE AXIS CHARACTERISTICS IS INDICATED BY (**) . 

THE FILE NO. IS THE SEUUENCt NUMBER OF THE VARIABLE IN THE FILE 
OBSERVATIONS. THE FIRST VARIABLE IS TO BE THE INDEPENDENT VARIABLE X 
AND VARIABLES 2 AND 3 ARE TO BE PLOTTED ON THE LEFT HAND Y AXIS. THE** LINE** 
ENTRY IDENTIFIES THE TYPE OF L I NE ( CONTINUOUS OR DOTTED) AND THE **GR APH** 
ENTRY IDENTIFIES THE TYPE OF PLOTJ POINTS. LEAST SQUARES. FILL IN LINES. E.T.C.). 
THE **CODE** ENTRY IDENTIFIES THE CODE FOR THE TAG THAT FOLLOWS IN THE NEXT 
CARD. 

THE GENERAL SPECIFICATIONS FOLLOW WITH THE **STOP** CARD INDICATING 
THE END OF DATA INPUT FOR THE FIRST PLOT. 
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APPENDIX C 
FORTRAN-ALGEBRAIC EQUIVALENCE 
OF MATHEMATICAL MODEL 
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The two systems of differential equations that were presented in 

PART TWO have to be converted into function subprograms for use with the 
DYNAMO Simulator. The FORTRAN format of the differential equation model 
is shown below for both of the cases illustated on pp. 14- 16. 

CASE NO. 1 The CSTR battery 

This is an example of straight forward application. The derivatives of 

of the concentrations of the reacting component in each of the tanks with 
respect to time are identified through subscript J and a computed GO TO 
statement : 



// DUP 

* DELETE. F 
// FOR 

•EXTENDED PRECISION 
♦ONE WORD I INTEGERS 

* LIST ALL 

FUNCTION F(JtL) 

COMMON JCARD<80) »LC< 70) t AM »DELX tCOEF < 40 > f I ND I C ( <K) > 
COMMON DIST(6»10) »X(5) »Y120>5)»IX(2)»IY(20»2> 
GO TO U *2 > 9 J 

1 F= 1. - Y(1»L) .5*Y(1»L>) 
GO TO 3 

2 F= Y(1»D- Y(2tL)*(l. + .5*Y(2»L)> 

3 RETURN 
END 

// DUP 

♦STORE WS UA F 



/// 
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CASE NO. 2 The RLC circuit 



This is a case where the higher order derivative must be reduced to a 
first order derivative. The reduction method can be outlined as follows: 



1. Set Y1 equal to the first order derivative 

2. The derivative of Y1 is the second derivative and it can be expressed 



in terms of the differential equation. 
3. The second equation, describing variable Y2 is the first order derivative, 
that is, d/dt(Y2) = Y1 

The same type of approach will reduce higher oder equations. 



// DUP 

♦DELETE F 
// FOR 

*ONE WORD INTEGERS 
♦ LIST ALL 
♦EXTENDED PRECISION 

FUNCTION F(J»L) 

COMMON JCARD<80) »LC(70) . AM . DELX . COEF < 40 ) »INDIC(40) 
COMMON DIST(6»10)»X(5)*Y(20*5)»IX(2)»IY(20»2) 

GO TO ( 1 »2 t 3 ) t J 

C FIRST EQUATION IS THE SECOND DERIVATIVE 

1 A«(1«/C0EF(3) )* ( (l./COEF(2) ) ♦Y ( 2 » L > +COEF U ) ♦Y U • L > ) 
F= -A 

GO TO 4 

2 F= Y(1»L) 
GO TO 4 

3 F=(l./COEF(2) )^Y(2»L) 

4 RETURN 
END 

// DUP 

♦ STORE WS UA F 



hooker 
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APPENDIX D 
LIST OF SYSTEM'S OPERATING STANDARDS 



C 
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DYNAMO STANDARDS FILES GENERATOR 



1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 
49 
50 
51 
52 
53 
54 
55 



NUMBER OF EQUATIONS o 

PROGRAM RETURN CODE 2 

FILE INITIALIZATION INDICATOR 

FILE NUMBER FOR THE FIRST INITIAL COND 

INTERRUPTION POINT INDICATOR Q 

RUN TITLE INDICATOR SWITCH 

PLOTTING INDICATOR SWITCH 

INITIAL CONDITION INDICATOR 

LISTING OPTION SWITCH 

LISTING AND/OR PUNCHING OF THE RESULTS 
LISTING FREQUENCY FOR 1132 PRINTER 100 

NUMBER OF PLOTS REQUESTED 

CURRENT INITIAL CONDIT. FILE RECORD 

CONTROL COMMAND INDICATOR 

LISTING OF THE TABLE OF VARIABLES 

UNEVEN FILL ALLOCATION INDICATOR 

NEXT INITIAL CONDITIONS FILE RECORD 

INTERRUPTED RUN INDICATOR 

NO OF INCREMENTS OF THE NUMERICAL INTE 

LAST CASE REGARDLESS OF ALL INDICATORS 

DISK USAGE INDICATOR 

STORE FREQENC Y ( RESULTS TO FILE) 

RESERVED FOR SYSTEM USE 

RESERVED FOR SYSTEM USE 

RESERVED FOR SYSTEM USE 

LOW BOUND/INITIAL CONDITIONS FILES 

MAXIMUM RETURN FOR REPEAT COMMAND 
START PUNCHING FH 
STOP PUNCHING Ffr 
INDICATOR SWITCH 



FILES AT 


REC. 





FILES AT 


REC. 





PLOT 


NO* 


1 





PLOT 


NO. 


2 





PLOT 


NO. 


3 





PLOT 


NO. 


4 





PLOT 


NO. 


5 





PLOT 


NO. 


6 





PLOT 


NO. 


7 





PLOT 


NO. 


8 





PLOT 


NO. 


9 





PLOT 


NO. 


10 





PLOT 


NO. 


11 






1132 PRINTER LINES/LINE OF OUTPUT 
PRINTER SKIP CONTROL 
FILES STORAGE FREQ« CONTROL 
INTEGRATION INTERVAL COUNTER 
PRINTER LIST CONTROL 

NO. OF NEXT ENTRY REC IN DATA FILE 



OUTPUT PAGE NUMBER 

TYPEWRITER LOG CONTROL 

LISTING FROM FILES STARTS AT REC. 

LISTING FROM FILES STOPS AT REC. 

RETURN FROM PLOTTING INDICATOR 














1 
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IBM Publications 

Manual No* 
H2 0-02 82-0 
C2 6-3750- 
C26-5933-3 
B2 0-0001-0 
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1130 Continuous System Modeling Program-Program reference manual 

IBM 1130 Disk Monitor System-Reference Manual 

IBM 1130 FORTRAN Language 

General Purpose Systems Simulator III 



tlooher 
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Abstract for December Common Meeting 

Robert L. Cushman 
ARCON Corporation 
Wakefield, Massachusetts 



THREE-BAR AND FOUR-BAR LINKAGE SYSTEM WITH 

PLOTTED OUTPUT 

A mathematical model of a linkage system is controlled by an array of 
inputs to plot out the path of the linkage intersection point. In addition, the 
system simulates turning the entire mechanism about a major axis. The 
output of the system has yielded some very interesting designs. 

In conjunction with this report, a list- oriented free field floating point 
input program has been developed. This routine enables the control program 
to modify only specified items of the system input. Under break character 
control, an automatic iterative procedure can be set up. 

Some sample outputs are shov n in the enclosed photo. 
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The System Reference Library 



I'm Gordon Goesch, Product Publications Manager, IBM, San Jose. There 
is a Product Publications group at each of the Development Laboratories, 
as well as a Programming Publications group at most of them. And, of 
course, there is a department in White Plains that prepares Application 
descriptions. These groups all provide input to the System Reference 
Library, and that, rather than my own department, is the subject of my 
remarks. 

A manual looks quite simple, and sometimes it's hard for our own field 
people and for customer people to understand why it seems so difficult 
to get a few manuals written, and then to get them delivered while they 
are still fresh. There is a great number of manuals that must be kept 
current and kept in stock, and record-keeping alone is a sizeable task. 
The System Reference Library is the current method of indexing and clas- 
sifying system manuals, and is the latest of a series of different methods, 
each designed to solve the problems that the previous methods couldn't 
handle. Problems created by new and very complex systems. This 
method isn't perfect either, as you are well aware, but we are certainly 
constantly trying to improve it. (And I have one improvement to announce 
today, a little later. ) 

That is the reason I am always happy to talk and listen to groups such as 
yours about our publications. It gives us an opportunity to discuss with 
you our Publication Library; its organization, its purpose, and its dis- 
tribution system - because even with a good system you must understand 
how to use it if it is to be effective for you. 

I think that this type of a meeting can be a two-way street for information: 
We explain the principles; you provide feedback. We do get feedback from 
you via Reader's Comment Forms - we want more of your comments and we 
certainly appreciate them. 

I don't know how knowledgeable you are about our publications; therefore, 
for the benefit of the new members and also for the updating of the veteran 
members, I'll run through a few slides which I think will tell you the 
publication story. 

By the way, you have probably seen the publications display in the main 
convention lobby. The display, I am sure, contains publications of interest 
to you. Many of the publications on display have been published since your 
last COMMON meeting. Feel free to examine them in detail but please do 
not take them away, as there is only one copy of each and we want everyone 
to benefit from the display. 
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Slide #1 
BOL 



Slide #2 
FYI 



To begin, we have what we call the IBM Branch Office 
Library. BOL contains a great amount of information, 
the major portion of which are publications for users 
of our equipment. 

In order to call your attention to those publications in the 
BOL that are For Your Information 



Slide #3 
Swamped 

Slide #4 
SRL 



Slide #5 
Library 
Shelves 



and to help you avoid being swamped by ordering blindly 
as the man shown in the slide 

we have developed the Systems Reference Library (SRL). 
As you probably know, the SRL is a rather extensive 
library system. 

To give you an understanding of how to approach this 
volume of material 



Slide #6 
Mr. SRL 

Helps Select 

Slide #7 
What, 
Where, 
How 

Slide #8 
System 

Slide #9 
System X 



Slide #10 



Slide #11 
SRL Key 



let Mr. SRL help you make the correct selection. 



He will acquaint you with the SRL and tell you: 

a. What is available 

b. Where you can get the information 

c. and, how you can go about getting it. 

You are probably interested in establishing a library 
for only one system type, 

and for only a particular configuration of that system. 

Considerable thought and effort was spent in the design 
of the Systems Reference Library, to allow IBM people 
and customer people to select that material that is of 
particular interest to them. 

Each SRL is an encyclopedia for a particular system - 
with separate publications for the major subject areas. 
It consolidates all the basic reference literature necessary 
for you to: Plan, Program, Install, and Operate that system, 

The key you need for opening any of the System Reference 
Libraries 



2 



/cza 



Slide #12 



is the SRL Bibliography for your system. 



Slide #13 

Bibliography 
& SRL 
Newsletter 



Currently there are 13 System Reference Libraries, 
ranging from the 1130 to the System 360 - and of course 
each system has its own separate Bibliography. 

Each Bibliography is actually an Index of all the current 
publications about a specific system. In it, publications 
are listed both by subject code and by machine number - 
and it contains abstracts describing each available publi- 
cation. (We will discuss subject code a little later. ) 

Now, how do we update the Bibliography? 

Each Bibliography has its own Newsletter (green for easy 
identification) and it is issued monthly (when there are 
changes). The Bibliography Newsletter updates the Biblio- 
graphy by: 

1. providing titles and abstracts of new publications 

2. providing form numbers of Technical Newsletters 

3. Listing type 1 programs and their latest modifi- 
cations, and 

4. Listing obsolete form numbers. 



Slide #14 
DPT 



Slide #15 
Series of 
DPTs 



Actually, the Bibliography newsletter is a current "Accumula- 
tive Index of Publications and Programs" available for a given 
system. 

To keep the Newsletter from getting too large, Bibliographies 
are periodically scheduled for revision - when that occurs, 
the information from the current newsletter is merged into 
Bibliography. 

An additional source of information is the "Data Processing 
Techniques" (DPT) Bibliography (Form F20-8172). It 
indexes a series of publications of techniques for Study, 
Analysis, Design, Implementation, Programming, Documen- 
tation, Installation, Operation, etc. 

This slide shows some of the DPT manuals. 



Slide #16 
KWIC 



Another excellent Index for your use is the KWIC Index of 
Marketing Publications (Form 320-1621). 
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Slide #17 
KWIC & 
TNL 



Slide #18 
3 Way List 
1-2-3 

Slide #19 
2 More List 
4-5 



It is published quarterly and updated by a monthly TNL. 

The KWIC Index is based on an abbreviated 30-position 
publication title - listing and cross-referencing publications 
by the important words in the title. 

The KWIC Index is listed in five ways: 

1. Alphabetically, by all key words in the title 

2. Machine or System Type 

3. Form Number 

4. Type I & II Programs in System Sequence 

5. Type III & IV Programs in System Sequence 

For example, this slide shows 3 separate word listings 
for a single publication - "Programs for Petroleum 
Engineering" 

and here, the same publication listed by machine number 
and by form number. 

The latest KWIC Index was prepared from 11, 546 publication 
titles which generated 29, 122 listings. 

Actually, the KWIC Index lists many publications other than 
SRL publications, such as Executive Guides and Brochures, 
tools and techniques manuals, applications manuals and 
briefs, educational material. 

Therefore, to start a System Reference Library, it is 
necessary that you work with your IBM representative, using 
the three key publications we have talked about, the: 

1. Bibliography and its Newsletter 

2. the DPT Bibliography 

3. KWIC Index of Marketing Publications 

You can select and build your own reference library to 
support your system. 

However, please do not order your publications by writing 
to Product Publications (the address shown on the manual) 
or our Distribution Center in Mechanic sburg, as it will 
only delay the order. You must order through your local 
IBM representative, and I will review the details of them 
shortly. 

Now lets talk about some of the other interesting and 
useful features of the library. 
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Slide #20 
SRL 

Masthead 



Slide #21 . 
SRL TNL 



Slide #22 
TNL 

Masthead 



Each SRL publication, listed in a System Bibliography, 
is identified by a file number and a form number, 
located on the upper right hand corner of the publication 
cover - as shown in the slide. 

The file number performs two functions: the first part 
specifies the system (s) number; the last two digits the 
Subject Code. The Subject Code structure is a group of 
two-digit numbers (00-99) assigned to the various system 
components, e. g. 

00 General System material; Bibliographies, System 
Summaries, Configurators 

01 Machine System (CPU) 
03 Input/Output Units 

05 Magnetic Tape Units 
20-50 Programming Systems 
60 Application Manuals 

The subject code 13 shown in this slide, indicates that 
this publication is about Special and Custom features. 

Incidentally, these subject codes are all defined by their 
use in Part I of each Bibliography. 

The form number is self explanatory; however, the form 
number suffix indicates the edition, or editorial level, of 
the publication. 

Because of the nature of computers and of the computer 
industry, it is frequently necessary to make changes to 
manuals. Just as green newsletters update the Bibliography, 
so do regular newsletters update any publication in the 
Library. 

In most cases TNL packages are made up of an identifying 
cover page and replacement change pages for the parent 
publication - when you receive such a TNL you merge it 
into its parent manual and throw away the old pages. 

Incidentally when you order a publication you will auto- 
matically receive the latest technical level copy as well as 
all the outstanding TNLs against that publication. 

This slide shows the upper right hand corner of a TNL. It 
indicates how the TNL identifies itself with its parent 
publication. 
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Slide #23 
SRL, NL 
Parent Pub. 
Manual 



It carries the file, number and form number of the 
parent publication it updates (and it is form-number- 
suffix sensitive) 

Below that is the TNL's own number, publication date of 
the TNL, and the form numbers of any previous TNLs 
outstanding against the parent publication. 

Incidentally, all page replacement TNL pages carry 
similar identifying information. 

Outstanding TNLs are incorporated into the parent publi- 
cation when it is being revised. TNLs may also be merged 
into the parent publication when it is being reprinted. 

Information regarding the technical level of a publication, 
and the TNLs that may have been merged into it, is printed 
inside the front cover of each SRL manual. 

This slide shows a manual, a corresponding TNL, and a 
green SRL newsletter. With this combination on hand you 
have all the publishing reference you need for the parent 
manual. 



Slide #24 
2 Biblios 
2 NLs 



Keep in mind that the best SRL publishing information source 
is the green SRL newsletter, because it not only updates its 
own parent publication (the bibliography) but also lists all 
the existing publications that are current for that system 
as well as their outstanding TNLs. 

and of course that each major system has its own 
bibliography. 



Slide #25 
In-Out 

Slide #26 
Wrapped Up 



Thus, the SRL system keeps you well posted on what is in_ 
(current) and what is out (obsolete) for an effective library. 



Basically, you have at your disposal a "living-doll 1 
library system. 



of a 



How can you get new manuals and TNLs after you have 
established your library? 

a. If you desire, you may continue ordering specific 
publications through the IBM Branch Office. 

b. However, you may prefer to use the SRL Sub- 
scription Service that the System Reference 
Library offers. 
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The SRL/SS provides automatic shipping of new and 
revised manuals, and newsletters, directly to you 
without having to go through the IBM Branch office 
each time. 

All Systems Reference Library manuals listed in SRL 
Bibliographies under subject codes 00 through 50 are 
available by profile. 

This distribution of publications according to profile is 
designed to provide you with a basic, master library 
tailored to your needs. 

Application Program manuals, Student Texts, Data 
Processing Techniques manuals, Course Description 
Bulletins, and other miscellaneous documents (except 
padded forms) listed in SRL Bibliographies under subject 
codes 60 to 99 can be subscribed to by form number. 

In addition, and this is new, revision service on multiple 
copies of SRL's and PLM's under subject codes 00 through 
50 may be ordered by form number. 

Here's how it works: 

To convert existing Revision Service Subscribes, special 
pre-printed conversion forms are being sent to all the 
sales offices. The salesman will review your needs with 
you and establish your "profile", which is basically a 
description of your system and your applications. You 
should also identify those publications you. want in multiple 
quantities and order the quantities you need. The salesman 
sends the form to the Distribution Center and you are in 
business. You will receive as many copies of the form- 
numbered publications as you ordered, and any new or 
revised (or newslettered) form that fits your profile. 

For new subscribers the system is the same except that 
pre-printed forms obviously won't be used. 

Slide #30 Now, you are all set, you know what is available, you 

SRL & Rev know how to select the publications, and you know where 
Pkg to get them. 



Slide #27 
SRL, TNL 
Revision 
Service 



Slide #28 
Card 



Slide #29 
Mailman 
w/pkg. 
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Slide #31 
The Key 
Is Yours 

Slide #32 

Key to 

Knowledge 
Slide #33 

SRL 



The key is yours. 



Use this key to open up a tremendous amount of timely 
knowledge about your system through the IBM Systems 
Reference Library. I hope that the result of all this, 
will make you as happy as the man in the next slide - 
careful planning of your library may help ! 

Most of you have probably noticed the Reader's Comment 
Form that is appearing on the back of many manuals these 
days. Some of you may have filled one or more out. The 
response to these has often been very gratifying and we 
appreciate it. 

I want to encourage you to use them, as it is one of the 
means, along with meetings like this, by which we get 
the feedback from our readers that is essential if we are 
to improve our publications and make them more useful 
to you. 

This form is self -addressed and post-paid and will be 
directed to the correct publications group. As a reminder, 
please don't use the form to order manuals as we have to 
redirect such orders back to the Branch Office with a 
consequent delay. 

On behalf of the publications groups, I want to thank you 
for your attention and for your comments, and pledge to you 
our whole-hearted effort in providing first rate publications 
support for your systems. 
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ABSTRACT FOR PROGRAM LIBRARY PROJECT 



Discussion of the proposed PREP Forms for the 1130 , 1800, and 
360 Library. There will also be a discussion of an extension 
of the minimal standards for this Library. It is requested 
that there be representatives from each of the machine system 
projects in the Systems Division present at this meeting. 



Speech for COMMON 



Linkage Editor 



I. Introduction 

45 minutes is a short period; therefore an overview 
II. Function of Editor 

A. Compiler turns a SOURCE module to an OBJECT MODULE 

B. Linkage Editor takes OBJECT & LOAD Modules as input 

1. Resolves external references (automatic library call) 

2. Replaces control sections, if required 

3. Produces aliases 

4. Creates a "relocatable" module 

C. Overlay structures 

1. 5 control sections without overlay 

2. 5 control sections with overlay 

3. An overlay tree 

a) Use of CALL or branch to cause overlay 

b) Automatic loading of segments 

III. Dynamic Overlay Capabilities 

A. LINK 

B. XCTL 

C . LOAD 



IV. Discussion of Partitioned Data Sets 
V. JCL and Control Card Example 



Speech for COMMON 



Data Management 



I. Introduction - general run-thru 

A. Allocation to a volume 

B. Allocation of SPACE if disk 

C. Retrieval of Data Sets by name alone 

D. Specify Data Set specs deferred to program execution 

II. Access Methods 

A. Sequential 

B. Indexed 

C. Direct 

D. Partitioned 

E . EXCP 

III. Device Independence (mostly with Sequential Methods) 

A. Characteristics specified by control card 

B. Characteristics specified by Data Set Label 

IV. Data Set Identification 

A. Use of Catalog & Indexes 

B. Generation Data Groups 

C. DS name not in program, DD name is. 

V. Qualities of Direct Access Volumes 

A. VTOC 

B. DSCB's & space accounting (must have label) 

VI. Qualities of Tape Volumes . 

A. Labeled, unlabeled, NSL 

B. Density 

C. TRTCH 

VII. Record Formats 



A. F 

B. V 

C. U 
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VIII. Interface with OS 

A. DCB 

B. DD card 

C. DS label 

D. DCB exit 

IX. Describing a Data Set 

X. Processing Program Description 

A. MACRF 

B. EODAD 

C . SYNAD 

D. EXLIST 
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PARTITIONED DATA SET 




SPACE FROM 

DELETED 

MEMBER 



AVAILABLE 
AREA 
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LOAD MODULE FORMAT 



V- \A 

Y (Object modules) Y 



TRANSLATABLE FORMAT (Symbolic) ■': 



O6 3S0 


SYS 1. 
NUCLEUS 


SYS 1. 
SVCLIB 


Any User 

PDS or 
SYS 1. 
LINK LIB 


SYS 1. 
LINK LIB 


SYS 1. 
SORTLIB 


SYS 1. 
COBUB 


SYS I. 
FORTLIB 


SYS1. 
PL1L1B 


Any User PDS 


SYS 1. 
MACUB 


Any User 
PDS or 
SYS I. 
MACLIB 


Any User PDS 




MP NUCLEUS 


Access 
Methods. 

Routines 


User 

Processing 
Pr<»;rams 


IBM- 
supplied 
Processing 
Programs 


Sort Merge 
Modules . 


COBOL 
Library 
Modules 


FORTRAN 

Library 

Modules 


PL I 

Library 
Modules 


User 

Object 

Modules 


IBM- 
supplied 
Macros 


User User 
Macros Subroutines 


User PL1 statements 
User 
COBOL 
Statements 


DOS 'S60 


Supervisor Transient User IBM- 
Routines Processing supplied 

Programs Processing 
Programs 


Precompiled Sort Merge COBOL FORTRAN RPC User 
1 routines Object Subroutines Subroutines Subroutines Object 
Modules Modules 


IBM- User User 
supplied Macros Subroutines 
Macros 


User 

COBOL 

Sutements 




Assembler Sublibrary 


COBOL Sublibrary 


CORE IMAGE LIBRARY 


RELOCATABLE LIBRARY 


SOURCE LIBRARY 
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LOADABLE FORMAT (Phases) 



X 



EDITABLE FORMAT (Object modules) 



X 



TRANSLATABLE FORMAT (Symbolic) 



Figure 8. ProgTam library correspondence between COS/360 and OS/360 



Object module 
or load module 



Input ^ 



Object module 
or load module 



Object module 



Input ^ 



Object module 




DOS/360 linkage editor 



Figure 9. Physical difference in linkage editor output of the operating systems 



12 



/ 



11 BA 


BOOK1 


BOOK2 


BOOK3 


CS9 Module 
CS10 four 
END E 


CSt2 Module 
CS13 »ix 
END F 


CS6 Module 
CS7 three 
CS8 
ENDG 



Primary Input Data Set 



ENTRY START 




INCLUDE LIBB(BOOKl) 




OVERLAY A1 





INCLUDE LIBB(BOOK2) 




OVERLAY A2 




INCLUDE LIBA(BOOK3) 




OVERLAY A2 




INCLUDE LIBA(BOOKl) 




OVERLAY A2 




CS11 




END D Module five 




OVERLAY Al 




INCLUDE LIBA(BOOK2) 





LIBB 


BOOKl 


BOOK2 


CS1 Module 
CS2 one 
CS3 
END A 


CS4 Module 
CS5 two 
END B 



CS 
CS 
CS 



CS 4 

CS 5 



CS 
CS 
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CS 
CS 



cs n 



Output Module 
librory 



CS) 
CS2 
Ci3 
CS4 
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CS6 
CS7 
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cm 

CS12 
CS13 

| entry point START 



Figure 35. Processing an Overlay Program From Libraries 
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Primary Input Doto Se 



INCLUDE LIBA (BOOK ! , 800K2) 
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Library 
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Figure 36. Processing an Overlay Program With Insert Statement 
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* V* *_ Kid 



ua sec contains 



PL 



/ //CO 



DD cards required for program execution 
EXEC PGM»».LKED.SYSLMOD 



cbje;t dae*(s) and linkage editor control statements 

///SYSL.IN DD « 

/// SP ACE- (102U,(200,20)) 



. ///SYSUT1 DD L'NI*r»CS^ 5 :'A > Sl:-,= -(SYSLM0D)), 
//'/ UNIT-SY^DA.DIjP-INEW.PASS) 



///SYSVA OD DP - D5,\iAMr>iCpr>ti:T(Oo'),SPAC£-(102'» > (t>0 > 20 t l)), C 
//VSYSP3INT D P " Sy'sCwT'A 



///LKF.D EX". C PC.i'I^Wf.,PA * ■■! » ' A a :~.F , LIST , LET > NCAL ' 



[//EDITG01 JOB l J SMi:h 1 .X-U^EVL.L-l 



gure 26. The Linkage Editor Step of an Edit and Execute Procedure 

Appendix A: Exarrples of Linkage Editor Processing 43 
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//jr/^ exec Pm--iBUrW 

//Smjl'JC/i db DSrffi/f)E s 6YSl> Ifftfj DSP -Oil) 
//SWTS DD — ' 

« 

//SiSPRlhjT DD SVX)ur=A .' 
/WU HX££ : P&fir-UHKSDIT. PAR®* 'lETJJST' 

« 

//sysuM do mf/m^Ysi. m> disp-o/j^ 
//sips gfg jv/gf g:^A y j^^ 

F-AF.CUT/N6- THE- PROCSDORS * 

766 01 j rtsr/m -proc , msizyt^ i . 

//SPJ- SYSP0NC.H M) . WlT^'dOjLWEL-Q/L)) D)S- (y^5 

^7/°^. SY37./7/ DO ^MV/),^ *• 5TPi . S^SPcWCH 
Dbl DD 

//SIP3. DDN bD / 
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CHAIN OF SYMBOLIC REFERENCES 



COMILED WITH OBJECT MODULE CREATED WITH DATA SET 







DCB 






DATA SET LABEL 




DCBNAME 




DDNAME 




DSNAME 




GET 






DD 





COMPILED WITH OBJECT MODULE CONTROL STATEMENT AS 

INTERPRETED AT JOB TIME 



SEQUENTIAL ORGANIZATION* 





CREATE 


ADD 


RETRIEVE 


UPDATE 


QSAM 


x 


x 


x 

/A 


DA 
ONLY 


BSAM 


X 


X 


X 


DA 
ONLY 



* APPLICABLE TO ALL DEVICES 
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PARTITIONED ORGANIZATION 





CREATE 


ADD 


RETRIEVE 
SEQ. 


BPAM- 


X 


X 


X 


BSAM 




REWRITE 
MEMBER 




BPAM- 


X 


X 


X 


QSAM 

(or BSAM) 
(ONE MEMBER) 




REWRITE 
MEMBER 





* DIRECT ACCESS DEVICES ONLY NO UPDATE 



Q 



DIRECT ORGANIZATION* 





CREATE 


ADD 


RETRIEVE 


UPDATE 


BSAM 


X 

(WRITE- 
LOAD MODE) 








BDAM 




X 


X 


X 



* DIRECT ACCESS DEVICES ONLY 



INDEX SEQUENTIAL ORGANIZATION* 





CREATE 


ADD 


RETRIEVE 
SEQ. 


UPDATE 
SEQ. 


RETRIEVE 
DIRECT 


UPDATE 
DIRECT 


UloAM 


v 

A 

(LOAD MODE) 




v 

A 

(SCAN MODE) 


v 

A 

(SCAN MODE) 






BISAM 




X 






X 


X 



* DIRECT ACCESS DEVICES ONLY 



ACCESS METHOD SUMMARY 



ORGANIZATION 


SEQUENTIAL 


INDEXED SEQUENTIA 




DIRECT 


PARTITIONED 


ACCESS METHOD 


QSAM 


BSAM 


QISAM 


BISAM 


BDAM 


BPAM 


LOAD 


SCAN 


PRIMARY MACRO- 
INSTRUCTIONS 


GET, PUT 
PUTX 


READ 
WRITE 


PUT 


SETL.GET, 
PUTX 


READ 
WRITE 


READ 
WRITE 


READ, WRITE 
FIND, STOW 


SYNCHRONIZATION 
OF PROGRAM WITH 
INPUT/OUTPUT 
DEVICE 


AUTOMATIC 


CHECK 


AUTOMATIC 


AUTOMATIC 


WAIT 


WAIT 
CHECK 


CHECK 


RECORD TYPE 
TRANSMITTED 


LOGICAL, F,V 
BLOCK U 


BLOCK 
F,V,U 


LOGICAL 

F V 


LOGICAL 

F V 


LOGICAL 
F,V 


BLOCK 
F.V.U 


BLOCK (PART 
OF A MEMBER) 
F,Y,U 


BUFFER CREATION 
AND 

CONSTRUCTION 


BUILD 

GETPOOL 

AUTOMATIC 


BUILD 

GETPOOL 

AUTOMATIC 


BUILD 

GETPOOL 

AUTOMATIC 


BUILD 

GETPOOL 

AUTOMATIC 


BUILD 

GETPOOL 

AUTOMATIC 


BUILD 

GETPOOL 

AUTOMATIC 


BUILD 

GETPOOL 

AUTOMATIC 


BUFFER 
TECHNIQUE 


AUTOMATIC: 

SIMPLE 

EXCHANGE 


GETBUF 
FREEBUF 


AUTOMATIC: 
SIMPLE 


AUTOMATIC: 
SIMPLE 


btTBUr 
FREEBUF 
DYNAMIC 
FREEDBUF 


GETBUF 
FREEBUF 
DYNAMIC 
FREEDBUF 


GETBUF 
FREEBUF 


TRANSMITTAL MODES 
(WORK AREA/ 
BUFFER) 


MOVE 

LOCATE - 
SUBSTITUTE 


LOCATE 


MOVE 
LOCATE 


MOVE 
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SYSTEM CONTROL FUNCTIONS 



DOS/360 



OS/360 



Device independence 
DASD extent information 

Space allocation-primary 

Space allocation-secondary 

Device allocation 



Cataloging data sets 
Cataloged procedures 
Systems residence 
Split systems residence 
Libraries 



Private libraries 
Job control language 



Link editor 



Relocatable programs 



Overlay 



No 

XTENT cards with 
absolute addressing 

XTENT cards at 
job time 

XTENT cards at 
step time 

Fixed at assembly 
time, but actual 
device addresses 
may be changed by 
job control cards 
at execution time 

No 

No 

2311 only 
No 

1 source 
1 relocatable 
1 core image 
(all on SYSRES) 

No 

Basic , easy to use 



Overlay, map 



Limited to MPS 
macro utilities 
and LIOCS 

Fetch 



Yes 

DD cards, DSCB with 
only space request 

DADSM 



DADSM, dynamically 

Dynamic allocation at 
execution time 



Yes 
Yes 

2311, 2314, 2301, 2303 
Yes 

n source 

n relocatable 

n load 

(on any DASD) 
Yes 

Extensive and therefore 
complicated, but use of 
cataloged procedures 
helps 

Overlay, map, XREF, 
mixed load, and object 
module input 

Yes 



CALL 

SEGLD 

SEGWT 
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SYSTEM CONTROL FUNCTIONS (Cont. ) 



DOS/360 



OS/360, 



Dynamic program loading 



End of program 
Timing 



Fetch 
LOAD 



EOJ 



Time of day in all 
partitions; interval 
timer in any one 
partition at a time 



LINK 

XCTL 

LOAD 

ATTACH (option 4 only) 
Return 

Time of day and interval 
timer in any partition 



Multiple wait 



TP only 



Yes 



DATA MANAGEMENT 



Sequential files 
Partitioned files 
Index-sequential files 



Direct access 



BTAM 



QTAM 
Graphics 



DOS/360 

Yes 
No 

Fixed records only 



Fixed records, 
undefined records; 
absolute track only. 
Extended search 
(to cyl end only) , 
multivolumes 



No burst mode 
devices on multiplex 
channel with TP 
devices. Official 
support for 7770/72 
and 2780. Support 
for 2260 local and 
remote 

With multiprogramming- 
option only 

No 



OS/360 

Yes 
Yes 

Fixed and variable 
records , automatic 
record deletions , 
dynamic buffers 

Fixed, variable, and 
undefined records; 
absolute and relative 
track. 

Automatic insertions, 
multivolumes, extended 
search (to cyl end) , 
dynamic buffers 

MFT and MVT only. 
No support for 
7770/72, 2780, or 
2260 local 



MFT and MVT only 



Yes, 22G0 and 2250 



c 
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DATA MANAGEMENT (Cont.) 



Data set specification 
User standard labels 



Nonstandard labels 
Level of support 



Buffering 



DOS/360 



DTF only 



Sequential: header 
and trailer 
Direct: header 
index-sequential: 
none 

n program routines 

Queued (update, 
move, locate) 
Basic (index-sequen- 
tial, direct, and 
work files) EXCP 

1 or 2 static • 
(GETBUF, FREEBUF 
in BTAM only) 



OS/360 

DCB, 
DD, 

label information 

All organizations 
supported mid '67 



1 system routine 

Queued (update, locate) 
Basic (all access meth- 
ods) EXCP 



n dynamic (OPEN, 
GETPOOL, BUILD, . 
GETBUF, FREEBUF 
macros) 



LANGUAGES AND SYSTEM COMPONENT SIZES 



DOS/360 



Equivalent OS/360 



High Performance OS/360 



Assembler 

COBOL 

FORTRAN 

PL/1 
SORT 
RPG 

Link -edit 

Scheduler 

Supervisor + 
other resident 
routines for 
workable system 

Minimum 
partition sizes 



10K 
14K 
10K 

10K 
10K 
10K 
10K 

10K 

6K-10K 



10K background 
2K foreground 1 
2K foreground 2 



18K 
17K 
16K 



15K 
15K 

18K 

PCP 14-20K 
MFT: 26-36K 



PCP: 18K 
MFT: 18K 
per partition 



44K 

80K 

12 8K (G) 
200K (H) 

44K 

17K 



18K 
44K 
88K 

44K 
100K 



MVT: 100K and up 



MVT: 44K 
per partition 
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File 
Organization 


DOS/360 


OS/360 


Index Seq: 






Location master index 


Contiguous with 

evlindPT itiHpy 

W ViiUViCx lilUCA 


Any place on any DASD 
device 


Highest -level index with 
random processing 


Called in from 
DASD device 


May reside in core 


Prime data area 


Must be single, 
contiguous extent 
within volume 


Can be multiple extents 
within volume 


Record deletion 


User responsibility 


Automatic deletion of 
tagged records 


Direct: 






Multiple track search 


Limited to cylinder 

VsJ UXlUclX V 


Can search complete 
data set 


Relative track and 
block addressing 


No 


Vac 

xes 


Track overflow 


No 


Yes 


Partitioned Data Sets 


No 


Yes 
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DOS/360 


OS/36 0-M FT 


Maximum I/O Areas: 






. Seq. file 


2 + work 


No limit 


Index seq. direct 


1 + work 


No limit 


Buffering Techniques: 






Simple 


Yes 


Yes 


Exchange 


No 


Seq. files only with 
restrictions • 


Buffer Generation 


Compile time 


Compile, or dynamically 
by OPEN 


File I/O Characteristics: 


DTF 


DCB 


• Assigned at - 


Compile time 


Compile or execution time 


Device independence 


No 


Yes - within devices using 
same file organization 


Data Set Concatenation 


No 


Yes 
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Sequential 


Indexed-Sequential 


Direct 


T elecommunic ations 


Graphics 


Read/write 


Get/Put 


Read/write 
(partitioned) 


Read/write 


Get/Put 


Read/ write 


Read/write 


Get/Put 


Basic 


DOS/ 360 


SAM 


SAM 


none 


• ISAM 


ISAM 


DAM 


BTAM 


QTAM 


none 


OS/360 


BSAM 


QSAM 


BP AM 


BISAM 


QISAM 


BDAM 


BTAM 


QTAM 


GAM 



o 



— — — — ■ _ 


BS 


AM* 


QSAM 


BP AM* 


BISAM 


QISAM 


BDAM* 


Format F - unblocked 


DOS 


OS 


DOS 


OS 




OS 


DOS 


OS 


DOS 


OS 


DOS' 


OS 


Format F - blocked 


DOS 


OS 


DOS 


OS 




OS 


DOS 


OS 


DOS 


OS 


DOS 


OS 


Format V - unblocked 


DOS 


OS 


DOS 


OS 




OS 




OS 




OS 




OS 


Format V - blocked 


DOS 


OS 


DOS 


OS 




OS 




OS 




OS 




.OS 


Format U 


DOS 


OS 


DOS 


OS 




OS 










DOS 


OS 


* Deblocking and blocking of logical records must be don 


e by prol 


>lem pro 


gram.- 









Cylinder i 



• Prime data area • 



J 



Average seek * 100 cylinder* 



Example 2: OS/360 split data area 



08/360 
only 



-Prime data area 1- 



Prime data area 2 



Cylinder $ 



Average seek =• 50 cyl. 



99 100 101 



Average seek • 50 cyl. 
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A Batch Processing FORTRAN System 
for a Minimal Configuration IBM 1620 



This paper describes a software package designed to 
increase throughput on a 20K card system IBM 1620 
computer in an environment where a large number of 
fairly simple FORTRAN programs must be processed. 
The increase in throughput is accomplished in two 
ways; (1) programs are batch executed under control 
of a loader-monitor routine, and (2) a powerful pre- 
compiler reduces the number of execution errors and 
decreases the requirement for on-line debugging. 

The compiler is a version of the PDQ FORTRAN compiler 
which has been modified to handle the batch processing 
features of the system. Batch execution is made 
possible by keeping the entire subroutine library 
resident in core rather than reloading it with each 
object deck. Object programs, separated by control 
cards, are stacked for input. The reading of a control 
card by the FORTRAN card read subroutine or the execu- 
tion of a CALL EXIT statement will cause the next 
object deck to be automatically loaded and executed. 
The monitor will also terminate a job if the output 
line count exceeds a control card specification. 

The precompiler detects more than seventy distinct 
errors based on PDQ FORTRAN specifications. Many 
of these errors, such as undefined symbols, are un- 
detected by the compiler and cause execution check- 
stops. Recognition of multiple errors in a single 
statement is possible, thus eliminating multiple de- 
bugging passes. 



WILLIAM G. LANE 
CHICO STATE COLLEGE 
HICO, CALIFORNIA 



DEAR MR. LANE, 



0^ 



PLEASE EXCUSE THE USE OF THIS TYPING FOR A LETTER, BUT I CAN 
PUNCH CARDS FASTER AND MORE ACCURATELY THAN I CAM TYPE. ALSO, I 
DO NOT HAVE A SECRETARY AT THE PRESENT TIME. 

MY MAIN PURPOSE IN WRITING TO YOU IS TO ASK IF THERE IS A SLOT 
IN THE 'COMMON' MEETING FOR TWO PAPERS, ONE OF WHICH I MENTIONED 
TO YOU IN SEPT. THESE ARE THE SAME TWO PAPERS I GAVE IN SEPT., BUT 
I THINK THERE WILL BE ENOUGH PEOPLE WHO COULD NOT COME TO THE 
MEETING IN SEPT. TO BE WORTHWHILE FOR ANOTHER PRESENTATION. 

I HAVE TWO PAPERS, ONE SPECIFICALLY FOR THE 1620, AND ANOTHER 
OF A MORE GENERAL NATURE. THE PAPERS SHOULD NOT NEED MORE THAN ABOUT 
10 - 15 MINUTES. THE ABSTRACTS ARE - 



1) 'A LARGE 1620 DISK OPERATING SYSTEM, REASONABLY 7094 COMPATIBLE.' 

A NEW MONITOR FOR A 40K OR 60K 1620 HAS BEEN DEVELOPED AT 
PRINCETON FOR USE AS A DEBUGGING AID FOR THE 7094 AND SOME 360/OS 
PROGRAMS. FN II I/O AND FN IV I/O ARE INCLUDED AS WELL AS 
PRIVATE STORAGE OF PROGRAMS. MANY CONTROL CARD OPTIONS EXIST. 
SPEED CAN BE 2 TO 4 TIMES FASTER THAN MOM-I (IF ONE HAS HARDWARE 
FLT . PT.) BOTH IN COMPILATION AND EXECUTION. A USERS MANUAL 
DOES EXIST. MANY STUDENTS ARE PRESENTLY USING THE SYSTEM 
ON A COMPLETELY OPEN-SHOP BASIS. 



2) 'BASIC PROBLEMS Or INFORMATION RETRIEVAL AND A SOLUTION ON 
THE 1620. • 

SOME OF THE BASIC PROBLEMS OF INFORMATION RETRIEVAL AND 
IMPLEMENTATION ARE DISCUSSED. THE TECHNIQUES OF FILE-ORGANIZATION 
ARE DISCUSSED. THESE TECHNIQUES ARE DISCUSSED FOR THE MOST :OMMON 
FILE DEVICES (DISK AND TAPE). A SOLUTION IS SHOWN FOR THE 
1620 WITH DISK TO DEMONSTRATE DISK UTILITY. 



I AM SORRY ABOUT THE LATENESS OF THIS, BUT I HAVE BEEN 
OUT OF TOWN FOR SOME TIME AND CAN ONLY GET BACK FOR WEEK-ENDS AT 
THIS TIME. I HOPE TO SEE YOU IN S.F. 



VERY TRULY YOURS, 



IS}""'*® 

NOV 11967 
C.S.C. COMPUTER CENTER 




L ANN Y HOFFMAN 
COMPUTING GROUP 
GUGGENHEIM LABS 
PRINCETON, N.J. 
08540 
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I. INTRODUCTION 

This paper describes the program written to provide programming 
support for the 1896 Communication Adapter used to attach start/stop 
terminals such as the IBM 1070,1050, 1030, and System/360 via 
2701, 2702, or 2703 Communication Adapters to the 1800 control 
system. The initial 1896 support was written as a joint effort 
between the Flint, Michigan branch office and the Chicago North 
branch office to support 1800/1070 systems. The project was 
started in February of 1966 and we were able to run 1070's, 
though somewhat erratically, by November of that year. An 
1800/1070 Type III package running under TSX II was submitted 
a few weeks ago to PID. The authors are Norm Rawson and 
Chuck Reiling of the Chicago office, and myself of the Flint 
office. Implementation has taken roughly five man-years of 
time, and five years off each of our lives. You are recommended 
to the paper being presented by Charles Jonas of The Dow Chemical 
Company to hear the other side of the story, the user's. 

The original commitment to the customer specified that the 1896 
Support would be accessed via FORTRAN and run under the 1800 
Time Shared Exceutive (TSX), with little or no loss of the 
capabilities of either the 1800 or TSX. 

We also required ourselves to consider the following three points: 
1. The 1800 Control System is at least three magnitudes of 

speed faster than the terminals, implying that we not hold 
the 1800 to wait for a communication function to be performed. 
This requirement was reinforced by point 2 below. 
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2. An 1800/1896/1070 System may be co ntrolling more than one 
process, including processes interfaced through the 1800 
Process 1/0 features. 

3. The resulting system must not use more than 3000 words of 
memory (Skeleton resident). 

To fulfill these requirements, the system was designed to meet 
the following specifications: 

A. All user programming may be done in FORTRAN. 

B. All requests for communication functions will be placed 
in a priority queue. 

C. Upon completion of a requested function, a user specified 
flag will be set and, if the option is included, a mainline 
coreload may be placed on the TSX coreload queue (priority 
and coreload specified for each function requested). 

D. Printer output may be done via FORTRAN WRITE statements. 
£. The support should take less than 3,000 words of memory 

(i ,e, , run on a 16K 1800) . 

F. Multiple terminals per communication line, and multiple 
lines per 1800 will be supported. 

G. TSX will be altered the minimum amount possible so that 
TSX maintenance by FED will not be sacrificed more than 
necessa ry. 
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The above specifications have been met. The use of the FORTRAN 
WRITE statement for 1053 output required the modification of 
either FORTRAN I/O or Skeleton I/O; we chose what we felt was 
the lesser of two evils, and modified TYPEN in Skeleton I/O. 

1 1 • TERMINAL DESCRIPTIONS 

The following brief descriptions of the various Start/Stop 
Terminals available are meant to present the operating differences, 
and the capability of each pertinent to the discussion that 
follows. For more detailed information, please see the appro- 
priate reference manual. 

IBM 1070 Process Communication System (Form No. A26-5989) 
The IBM 1070 system is a tele-processing system designed to 
monitor, supervise, and control widely spread process areas. 
Two-way transmission between a remote 1070 System and a central 
station is over standard voice or sub-voice grade communication 
lines. A 1070 System consists of a 1071 Terminal Control Unit, 
1 or more 1072 Terminal Multiplexors, plus options to allow 
analog input, digital input, digital output, pulse counters, 
pulse output, 1053 Printers, manual entry stations, and display 
units. Transmission speed is selectable from 134.5, 600, or 
1200 baud. See Diagram 1 for a schematic. Diagram 2 gives 
some examples of character exchanges necessary to perform 
certain functions. Analog Input is received as a series of 
three digits for each point scanned, representing a count 
between and 7999 proportional to the signal attached. 
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The 1070 Process Communication System will recognize 5 
function codes: 

- Conditional take from address 

5 - Unconditional take from address 

6 - Conditional take from present address 

7 - Unconditional take from present address 
9 - Send 

In addition, the 1070 can be set to random or sequential operating 
modes, and, on send, the printer output channel may be selected. 

Termi nal Add res s i ng is a sequence of 3 characters transmitted 
from the 1800 that specifies the terminal and function wanted. 
The three characters and their use are: 

1. EOT -(c)" Calls to attention all terminals on that line. 

2. ' A - The address (one alpha character) of the terminal 



The 1070 Character Coding consists of bits BA8421 . The 1071 
Terminal Control Unit contains a 3-Digit Multiplexor Address 
Register. Random or sequential operating mode is selected by 
the presence or absence of the B-Bit in the hundreds digit. 
Printer Output Channel is selected by a B-Bit present in the 
unit's digit of this register. This register may be set by 



that is wanted. 



3. 



N 



The function (one BCD digit) that is 



requested . 
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a short SEND, i.e., ©A 9..(5)a M^^®, where' represents 
a positive response from the 1070. is the hundreds digit, 

the tens digit, and M^ the units digit that are placed in 
the 1071 Multiplexor Address Register. The B-Bits are placed 
in the correct digit by the program before this message is 
transmi tted . 



1050 Data Communicati o n System (Form No. A24-3474) 
The 1050 system is a tele-processing system designed to send and 
receive data in the form of cards, paper tape or manually. A 
system will contain a 1051 Control unit, plus any or all of 
the following units: Card Reader, Card Punch, Paper Tape Reader, Paper 
Tape Punch, Programmed Numerical Keyboard, Selectric Printers, and 
an Alphanumeric Keyboard. Diagram 3 shows a typical configuration 
and data exchanges with a central computer. 

The 1050 receives and transmits on standard voice or sub-voice 
grade communication lines at a rate of 134.5 baud. Addressing 
the terminal is done by a two character sequence consisting of 
a terminal address character and a device selection code. The 
device selection code also specifies whether data is to be sent 
or received. Multiple blocks of data may be sent or received 
without relinquishing control of the communication line. 
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2740 Communications T erminal (Form No. A24-3403) 
The IBM 2740 Terminal is a tele-processing Selectric typewriter. 
As such it has the capability of sending data inserted via the 
standard typewriter keyboard, or receiving data as a printer. 
The 2740 communicates with a central processor via standard voice 
or sub-voice grade communication lines. Diagram 4 illustrates the 
character exchanges necessary to communicate with a 2740. It is 
highly recommended that 2740 model 2's, with the buffer attachment 
be utilized for most efficient operation. 2740's normally operate 
at 134.5 baud, but with the buffer attachment, 600 baud rates can 
be used. 

Note that all three terminals use a slightly different adressing 
scheme and that all three utilize fill characters (©) to allow 
time for mechanical movements on carriage returns, tabulates, 
and warm up periods. On the 1070, filler characters are used 
on the 600 baud model to present output characters to the printers 
at a rate less than 14.8 characters per scond. 

III. H ARDWARE INTERFAC E 

The 1896 Communications Adapter interfaces to the 1800 via Process 
Interrupt - Voltage, and Electronic Contact Operate. Each separate 
communication line attached requires a full group of each. See 
Diagram 5 for a schematic of the interface. The programming 
system assumes interrupt assignments to level 0. The reasoning 
here is that with the exception of the 1816 Keyboard, this is the 
only device that has the possibility of data overrun without 
hardware failure. 
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Each group of process interrupt is wired into one bit of the 
level Interrupt Level Status Word, beginning with bit and 
proceeding through bit 15. In this manner an inherent priority 
is established for each line. However, once the servicing of 
a line has begun, it will proceed through to the BOSC 
instruction before any other lines are recognized. This takes 
somewhere around 750 usee, on a 4 usee. CPU. 

Except for the fact that the level exit from MIC has been 
modified, there is no other good reason to restrict level zero 
to just the communications adapter, although not too many people 
will accept responsibility if that restriction is not honored. 

1 v • GEN ERAL DESCRIPTION OF SYSTEM 
The system may be divided into four logical areas: 
1 . Subrouti ne L INOP 

2. CAISS A subroutine containing 

a. Supervisory Routines 

b. ISS - Interrupt Servicing Subroutines 

3. 1053 Support 

4. CATST t The error coreload. 

Each of these areas is described briefly below. 

Subrout ine LI NOP 

This subroutine, callable from FORTRAN, is the user's means of 
requesting a communication line operation. The user has a 
choice of having an indicator set for him at the completion of 
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the requested function (LINOP), or he may have the system 
execute a CALL QUEUE (LINWQ), placing a designated mainline 
coreload on the TSX queue in addition to setting the indicator. 
LINOP, which is used here to designate both calls, contains 
a 1 ine-operation-request queue which the Supervisor may 
interrogate, plus the necessary queue maintenance routines. 

CAIS S Subroutine 

This subroutine is defined as an ISS Subroutine, allowing the 
definition of a separate entry point for each ILSW bit used, 
plus a CALL or LIBF entry point. The ILSW bit 'entry points are 
entries to the ISS portion of CAISS. The CALL entry point is 
defined at Skeleton Build as the servicing subroutine for a Program 
Setable Interrupt that is assigned to the Supervisor portion of CAISS, 
Brief description of the Supervisor and ISS portions of CAISS 
f ol 1 ow : 

S u pervisor 

The Supervisor is not a separate program or subroutine as 
in LINOP, but is a set of routines, contained within the 
CAISS package, to provide services to the Interrupt Servicing 
Subroutine (ISS). The Supervisor is entered by a CALL LEVEL, 
said level being below that of the ISS itself. This allows the 
Supervisor to perform its tasks without interfering with 
the servicing of 1896 CA interrupts. The Supervisor builds 
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line operations for CAISS from the user's queue entry, 
does data- table chaining, halts typing on 1070's to allow 
scanning, removes completed line-operation requests from 
the queue, saves error information for the error coreload, 
and in general acts as an assistant to CAISS and an inter- 
mediary between the user and CAISS. 

ISS 

These routines service the interrupts of the 1896 Communi- 
cation Adapter, sending and receiving data to and from the 
terminals. To TSX it appears as a special I/O Subroutine. 

1053 Support 



The 1053 Support consists of modification to TYPEN in TSX, so we 
may intercept typewriter messages just prior to their output to 
non-existent 1053's attached to the 1800. These messages are 
placed on the disc, since the non-existent 1053's are defined as 
always being busy. 

When a line is free and has no queue entries waiting, CAISS initiates 
a special TYPEN function to recall these messages from disk. 
These messages are then converted to BCD code, fill character (T) 
counts are inserted, and a CALL LINOP is performed. The 1896 
Support System thereafter handles this entry as any other. 
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An additional feature called Type-Stop was put in to allow 
the 1070 users to halt the typing of a 1053 message, perform 
control functions and/or input scanning, then resume the 
typing where it was interrupted. 

CATST - The Error Coreloa d 

Errors are handled in a rather elementary fashion to get around 
core limitations. When an error is detected, the contents of the 
work area for that line are transferred to an error buffer, and 
the whole operation is retried. After a set number of retries, 
the operation is aborted and terminal is marked down. Any other 
queue entries for that terminal are attempted and if any are 
successful, the terminal is set back up. The abortion signals 
for the queueing of the error coreload - priority and error 
parameter of 1. This coreload prints out a message on a designated 
unit, can dump the error buffer and other information on the list 
printer, keeps counters updated, and tests terminals that are 
marked down by the simple method of addressing them. If the 
terminal answers, it gets put back up on line. The error coreload 
is also queued up periodically by CAISS for counter update and 
terminal tests. 
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Design Consideration 

The structure of the support is the result of trying to satisfy 
the considerations mentioned above in Section I, plus a few 
factors which were not known at the initial specification. These 
factors were: 

a. The specific hardware design of the 1896 Communication 
Adapter and its interface to the 1800. 

b. The need to service at least six 1200 baud lines. This speed 
means there is only 7.5 milliseconds between characters on 

a line and l/6th of that allows us only 1.25 m/sec. per line 
for a maximum service time on the CA interrupt level before 
we start to lose data. On a 4 microsecond 1800, this is 
approximately 65 instructions, using San Jose's estimate 
of 20 usec/i nstructi on . For this reason, a high percentage 
(90+) of the coding is in one-word, indexed instructions, 
which run approximately 10 usec/i nstructi on , allowing us 
about 120 instructions (which merited a minor sigh of relief). 



Because of this time limitation, we have, wherever possible, delegated 
jobs to the Supervisor, letting the 1896 - CA idle if necessary. 

IV. LINE OPERATION REQUESTS 

Functi ons. : 

^ 

All line operations are initiated from CALL statements to a 
skeleton resident line operation routine. The following line 
functions will be provided: 
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1070 Function Codes: 

- Conditional TAKE from zero multiplexer address 

5 - Unconditional TAKE from zero multiplexer address 

6 - Conditional TAKE from user specified multiplexer 

address 

7 - Unconditional TAKE from user specified multiplexer 

address 

9 - SEND to user specified multiplexer address 
11 - SEND to 1053 Printer 

A terminal multiplexer may be set to either random or sequential 
operating mode, and the 1053 Printer Output Channel may be 
selected on a direct send (specify cuntion Code 11). 

1050 Functions (Device Selection Codes ) 

Polling (Take from 1050) Sending to the 1050 

- Any input component 1 - Printer 1 

5 - Keyboard 2 - Printer 2 

6 - Reader 1 3 - Punch 1 

7 - Reader 2 4 - Punch 2 

9 - Any or all output components 
that are in a steady status 



2740 Function Codes 

Being a relatively simple device, the 2740 functions are relatively 
simple. A function of (zero) requests data from the 2740 keyboard, 
its only input device, while any non-zero value will send data to the 
2740 printer. Period. 
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Cal 1 Statemen ts : 

Three line operation subroutines are provided: 

a. LINOP (line operation) which maintains an indicator 
for the line operation status. 

b. LINWQ (line operation with queue) which queues a 
mainline coreload when the line operation is 
complete and maintains the operation status 
indicator. 

c. TYPSP (type stop) which interrupts an 1896 message 

of priority 255 in favor of a more important operation 
on that line, and then comples the message when the 
line is again available. 



Subroutine LINOP is called either by one of the following call 
sequences 

1. FORTRAN: CALL LINOP (LF, LP, LL, LT, NDATA, IND) 

2. ASSEMBLER: CALL LINOP 



DC 


LF 


Note: 






FORTRAN ARGUMENTS 


DC 


LP 


LF, LP, LL, LT, LTSXQ . 






may be integer constant 


DC 


LL 


or variables, other 






arguments are integer 


DC 


LT 


variables. The ass ern brer- 






constants are the addresses 


DC 


NDATA 


of the arguments. 


DC 


IND 
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Subroutine LINWQ is called by either of the following call sequences: 

1. FORTRAN: CALL LINWQ (LF, LP, LL, LT, LDATA, IND, LTSXQ, 

QUEUE, CLDNM) 

NOTE: Program names QUEUE and 'CLDNM' must appear in 
an EXTERNAL statement in the calling progam. 

2. ASSEMBLER: CALL LINWQ 

DC LF 
DC LP 
DC LL 
DC LT 
DC NDATA 
DC IND 
DC LTSXQ 
CALL QUEUE 
CALL CLDNM 

Subroutine TYPSP is called by either of the following call 
sequences : 

1. FORTRAN CALL TYPSP (LL) 

2. ASSEMBLER: CALL TYPSP 

DC LL Address of the line number 

Definition of parameters for LINOP, LINWQ, and TYPSP: 

a. LF - Function code, - F ]6 (0 - 15 1Q ) stored as a 
one-word integer, only the low order of 4 bits are 
used. 
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b. LP - Priority to be assigned to this line operation 
by the 1896 Line Control Supervisor. LP is a one- 
word integer, between and 254. LINOP uses the 8 
low order bits as a positive number. Zero (0) is 
considered the highest priority and 254 the lowest. 



FORTRAT 'WRITE' statements to a 1053 are automatically 



c. LL - Line number, a one-word integer between and 15, 
only the low order 4 bits are used. This number 
references the Communication Adapter (CA) attached to 
that ILSW bit specified by LL. The 1800 Interrupt 
handling technique implies an order or priority with 
ILSW bit being the highest if two or more interrupts 
are simultaneous on the same level. 

d. LT - Terminal on the specified line. LT can range from 
1 to 16 with LINOP or LINWQ converting to the alpha 
addressing character A-P. Terminals on a line are 
required to be assigned starting with A and proceeding 
consecutively. Neither LL nor LT may reference a 

' higher numbered line or terminal than has been assigned 
at system generation time or a L I NOP error will result. 

e. NDATA - This is the low core (FORTRAN high subscript) 
address of user's data table. Data table format is 
explained below. 



given priority 255. 



*0 
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f . IND - is an integer indicator which will be set at 

various stages of the line operation. The value IND is 

set to depend on the status of the line operation. 

IND = 1 - Line queue was full, unable to enter request 

IND = 2 - Request entered in line queue successfully 

IND = 3 - Line operation complete with no errors 
(CLDNM has been queued) 

IND = 4 - CALL paramenter in error , request not entered 

IND = 5 - Repeated line operation failure, request can- 
celled (CLDNM has been queued) 

IND = 6 - Line or terminal down (inoperative), request cane. 

The user may elect to have the real-time clock returned 

with the operation complete (3 or 5) indicator. In this 

option, user must dimension the indicator as two adjacent 

words (as DATA IND, IND2/0,0/). Indicator value will be 

returned in IND and clock in IND2 , the next lower core 

address. Format of CALL LINOP is not changed. 

g. LTSXQ - This integer is the priority used if the user 
wishes the 1896 Line Control Supervisor to issue a CALL 
QUEUE at the completion of the line operation. LTSXQ 
may have any value from 1 to 32767. It cannot be zero. 

h. QUEUE - A dummy parameter which indicates the following 

argument is a coreload name. 

i. CLDNM - is the name of a core load to be used by CAISS 
in a CALL QUEUE (CLDNM, LTSXQ, X). (X is assigned by 
the user at system generation and determines if the 
lowest priority entry is replaced or the queuing is 
ignored when a queue overflow occurs.) Note that the 
coreload is queued on an unsuccessful line operation 
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(IND indicator of 5) , as well as on a successful opera- 



tion (IND indicator at 3) . 



The type stop call is provided for rapid recognition of interrupts. 
It. will suspend typing in favor of more important operations on a 
line. CALL TYPSP will stop typing at completion of the current 
character and will allow the line queue to be scanned for other 
line requests . When no more entries remain in the line queue , 
typing will be continued at the point of its interruption. This 
call should be issued from any interrupt servicing subroutine 
that requires line access in less time than the maximum typing 
requirement. For example, a 600 baud line will require in excess 
of ten seconds to complete an 130 character message. 



TYPEWRITER OUTPUT 

The 1800/1896 Process Communication and Control System provides 
two methods of typewriter output to the 1053: 

1. Normal FORTRAN 'WRITE' operations with a 'FORMAT' 
statement. 

2. Direct line operations CALLED by the user. 
FORTRAN 'WRITE' STATEMENTS : 

The TASK program of TSX has been modified to handle output to 1053 
typewriters on the 1896 system from the normal FORTRAN I/O sub- 
routines . Typewriters are assigned logical unit numbers for FORTRAN 
when the TSX system is built by the user, and the user initiates 
a message with the 'WRITE' and 'FORMAT' statements. In TSX, all 
FORTRAN typewriter messages or message units are buffered to disk, ( 
occupying one sector per message unit . Control is returned to 
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the user program immediately after buffering . Buffered 1053 
messages are recalled by the RECAL subprogram whenever their 1896 
line is idle; therefore, typewriter messages have the lowest 
priority of all line operations , (priority 225) . The length of 
time between 'WRITE' statement and message typing is dependent 
upon the number of requests for that line which are in the line- 
queue. Messages are recalled from the buffer on a first-in, first- 
out basis; alert messages will be recalled before normal messages. 
In TSX, alert messages are recognized by the first character in 
the ' FORMAT ' statement being a "Ribbon Shift Up". If a typewriter, 
or its line, is down, a backup typewriter specified by the user 
can be used. Error conditions such as disk buffer overflow are 
handled by a modified TYPEN program of TSX. A maximum of 16 
typewriters, one of which must be an 1800/1053 typewriter, may 
be supported by the 1800/1896 modified TSX system. 

Because both 'Printer Start' and 'Carriage Return-Line Feed' opera- 
tions are very time consuming, the user may take the option to 
permanently wire 'ON' his 1053 typewriters and to have the FORTRAN 
generated CRLF at the beginning of each typewriter message, 
automatically deleted upon recall. With this option, message 
units may not be used, and it is the user's responsibility to 
place CRLF where needed. If the option is not taken at system 
generation time, a printer start character is automatically 
placed before the message unit or CRLF of the message when the 
message is recalled from disk buffer. 
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Direct Line Me s s a g e s : 

An emergency 1053 message may be sent with priority over other 
operations on that 1896 line by using CALL LINOP or LINWQ and a 
data table containing the message. Function code is an 11 in the 
user's CALL, conversion code is 4, and random mode bit (XCM in 
data table) must be on. Data format is valid 1070 character in 
left 8 bits and filler count in right 8 bits of each data word. 

SEQUENCE OF OPERATIONS 



The following sequence of operations is initiated by the user v/ith 
CALL LINOP or LINWQ: 

1. User CALL from normal or interrupt program. 

2. a. Request processing by LINOP on same level as user, 

set user indicator . 

b. Enter request in line-queue. 

c. Set programmed interrupt for CAISS supervisor. 

3. a. Recognition of programmed interrupt. 

b. Search line-queue for highest priority request. 

c. Build line-operation tables for terminal and multi- 
plexer addressing. 

d. Trigger first interrupt from Communications Adapter. 

4. a. Level interrupt for CAISS 

b. Device addressing. 

c. Data transmit and receive. 

d. Longitudinal redundancy check. 

e. Clear line and set programmed interrupt for CAISS 
supervisor . 

5. a. Recognition of programmed interrupt. 
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b. Set line not busy, set user indicator. 

c. Call diagnostic coreload if error has occurred. 

6. User program recognizes operation complete code in 
user indicator . 

DA TA TABLES (Diagram 5) 

The data tables required by the 1896 system are modeled after 
the normal 1800/1130 data tables . The address transmitted in 
the call sequence points to the low core end of the table, re- 
quiring in FORTRAM the high subscripted end. The first word 
in the data table is a word count specifying the number of words 
of data or the number of characters to be transmitted or re- 
ceived, depending on the conversion code. The high order bit is 
the chain indicator bit if this option is included. If the 
chaining option is not included, this bits presence will be ignored. 
The system uses the low order 14 bits as a positive integer. 

The second word specifies the conversion code in the high order 
4 bits, and for 1070 systems, the multiplexor address and mode 
in the low order 12 bits. The conversion codes available are: 

- Unpacked, one character per word. 

1 - Packed Digital, two characters per word. 

2 - Unpacked Digital, one character per word. 

3 - Analog Input (1070 only) — the converted binary 

value of one analog input point is stored in 
each word. 

4 - 1053 output, the character to be printed is in 

the high order 8 bits, the number of filler 
characters to follow is in the low order 8 bits . 

5 - Packed, two characters per word. 
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The difference in digital or normal conversion is the handling of 
the BCD zero, consisting of the 82 bits, which is converted to a 
binary in Digital conversion, but left as a binary A (IO^q) in 
normal mode; plus that Digital conversion concerns itself with 
only the four low order bits and ignores any higher order bits . 

The Chain Address word must be present and set correctly if chaining 
of data table is used. The contents of this word is used with no 
checking as the address of the next data table. Bad things could 
come of an incorrect setting here. Note that in MPX , a load 
address function is provided to allow setting of this chain ad- 
dress that is remarkable similar' to the one provided by the 1070 
support package . 

SKELETON CORE REQUIREMENTS 

Approximate core requirements for the skeleton resident portions 

are given below. These core requirements are approximate and I 

will not be held responsible for them. 

TASK modifications for Typewriter support via FORTRAN I/O: 
620 Words . 

Subroutine LINOP/LINWQ plus the queue: 330 Words. 

The type stop subroutine TYPSP: 30 Words . 

CAISS Subroutine: 1200 Words plus 100 each for the chain 

on Send and Type-Stop Options plus 40 Words per line attached. 

The sum is about 2240 words for a reasonable system. 
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ABSTRACT 



FAST FOURIER TRANSFORM 
WITH APPLICATIONS FOR THE IBM 1800 



The Fast Fourier Transform technique as developed 
by Cooley and Tukey has had a widespread effect in the 
field of time series analysis. However, some difficulty 
has been encountered by potential users in determining 
exactly how the technique works. An effort to explain 
the derivation in detail will be made. 

Also, a description will be given of an analysis 
package program in which the East Fourier Transform 
technique is used to yield amplitude/phase spectra, 
power spectra, cross power spectra, and auto correla- 
tions. 



FAST FOURIER TRANSFORMS 



The algorith^for the computation of complex Fourier 
coef ffcients , as introduced by Cooley and Tukey 1 , has had 
a widespread <ftj:fect in the area of time series analysis. 
However, some difficulty has been encountered by potential 
users in determining exactly how the technique works. We 
will derive a special case for transforming a sequence with 
two factors and attempt to generalize the case for r factors. 



INTRODUCTION 

It is advantageous to review briefly the classical 
Fourier transformation in order to fully appreciate the fast 
Fourier transform (FFT) . Fourier's theorem says that any 
time series X(t) , which lias a finite number of discontinuities 
and is periodic (i.e., X(t) = X(t+T)), can be considered to 
be a linear superposition of sine and cosine terms whose 
arguments are integral multiples of the fundamental frequency 
w = 2tt/T. Mathematically this is to say 

Xft) = -7T a + J (a cos nu> t + b sin nu t) (1) 
v y 2 o L n v n o n o J K J 

n=l 



If we let 



1 , inu) t -into 
cos no) t = y (e J o + e J o ) 



and 



sin riw Q t = y-j (e J o - e J o ) 
We may rewrite (1) as 

00 

X(t) = c o + I cP V (2) 

H= - CO 

I 1/2 
Here we have let c =-^a , c =(a 2 +b 2 ) ' . i = /- 1 , u> =nu . 

o 2 o ' n n n J f J * n o 

Equation (2) is known as the complex Fourier series of 
f(t). Upon examining (2) it becomes evident that we can 
describe the sequence X(t) completely in terms of the c 
and w n . This is known as the frequency domain representation 
of the time series X(t) . The transformation from the time 
domain to the frequency domain is Fourier's transform and 
is written, where T is the time length of the series X(t). 



,1 . 
= f I XMe^V (3) 



T 
I 

1=0 

The function F(w) is in general complex, and 

F(u>) = RO) + jK» » |F(w)| e]* M 

The complete frequency domain representation of X(t) is 
given by 



|FO)'| * (R(a)) 2 + I (u>) 2 ) 1/2 (4a) 

and 

♦ (») = TAN" 1 (4{5j-) < 4b ) 

These equations represent the amplitude spectra and phase 
spectra of the given time sequence X(t) . 

LIMITS OF INTEGRATION 

Equation (3) represents the finite discrete form of 
the classical Fourier transform of the series X(t) . The 
summation is performed over the full time range of the 
series t » o— ■ »T. In order to satisfy the. orthogonality 
conditions 2 , which assure the validity of the transform, 
we must assume that the lowest frequency component we can 
transform is ia Q - 2ir/T. We must also bear in mind that 
when we use finite discrete sequences of X(t) , sampled at 
uniform intervals At, we are dealing with a band limited 
function subject to conditions imposed by the sampling 
theorem. The sampling theorem says that the highest fre- 
quency we can reproduce at a sample rate At is the Nyquist 
frequency w n . 



(5) 



If we have N points, spaced At apart, we can rewrite T as 



T = (N-I)At 



and 



w o = (N-I)at (6) 

Since we transform only on integral multiples of u> Q , we can 
readily determine the number of frequency components K, that 
we can expect to find in a sequence X(t) which is of total 
time length T at a sampling rate At 



Y % 2n/2At N-l 

w ~ 2ir/(N-l) At 2 



The sampling theorem goes on to assert that 



-(Nil ♦ i) " - i) °<i< ^ 



Which is to say that when we transform on frequency values 

N-l 

which lie between (— 2~) w ana " ( N ~ we can ex P ect an exact 
replication of the results we obtained in the region of values 
0<ja n <_ ^^*r^ w exce Pt that they are reversed in frequency. 



/9? 



We will see la*er that the FFT indexes frequency components 
from to (N-l)w Q . This is necessary in order for the algo- 
rithm to be useful in performing the inverse transform. 



The calculation of the complex Fourier coefficients from 
equation (3) requires a number of operations proportional to 
N 2 where N is the number of points to be transformed. Obviously 
this would require an appreciable amount of computer time when 
N is of a high order of magnitude. The technique as given 
originally by Cooley and Tukey 1 , and further developed by 
Sande and Gentlemen 3 reduces the number of operations required 
to the order of N log2N where N is conveniently composite (a 
power of 2) . 

THE ALGEBRA 

We may rewrite F(w n ) from equation (3) in terms of the point 
indicies if we let u> n » . 
Substituting in equation (3) 

F(n).- I x (t) e (Sfc) n=o,l,...N-l (7) 

T =0 

We have introduced the notation; 



THE FAST FOURIER TRANSFORM 



e(x) - e'* 2n 




Consider equation (7) for the case where N is the product 
of two integers AB. Notice that we may define any frequency 
index n in terms of A,B, and two new variables, a ! ,b'. 

n = b ' + a'B 

Similarly expressing the time index in terms of a,b. 
t - a + bA 

Where 

a, a' ■ o,l,.. . A-l 

b, b' * o,l, . . .B-l 

Substituting for t and n in equation (7) get 

crk . % ^ A r X B r 1 , . r (b'+a f B) (a+bA) ^ 
FCb'+a'B) =11 x(a+bA)e [ K — AB ^ ~J 

a=o b=o 

\ l B r X t .UA^ rab' aa' bb' ■ . 
* I I x(a+bA) e( M + _ + ^ + a'b) 

a=o b=o 

Since e(a'b) ■ 1 

= Y Y x (a + bA) edl'jetjfa'je^') 
a=o b=o 



We factor terms^ not depending on the inside summation to get 



a a o b-o 

Notice that the inside summation represents a Fourier trans- 
form of the B point sequence 

W a (b) = X(a+bA) 

The result of this shorter transform is multiplied by a shifting 
factor e(^|f) before becoming the A point input to the second 
transform over a. 

We have shown how an AB point transform can be defined in 
terms of 2 transforms of length A and B respectively. 
Sande has shown the expansion for the case where N has three 
factors ABC. 

F(c-b.C + a-BC) . V •(&') Y •(£') e(^f^) 

a=o b=o 

C-l 

I e (S£ ) x(a+bA+cAB) (8) 
c=o c 



Notice that as the number of factors we assign to N increases 
the shifting factors applied to each short transform become 
more complex. We can show a general form for r factors of N 
by letting 

N - tjt£ t r U\ - o,l,... (tx-1) 

u r = 0,1, . . . (t r -l) 

So that in general 

t « Ui + U2ti ♦ U3tit2 + ...u tit2...t (9) 

Similarly we may let 

n = v r + v r-l *r + v r-2 *r V2 (10) 

Where the following correspondence exists between the expansion 
for N having 3 factors and the generalized notation 

{A,B,C} - {t 3 ,t 2 ,t 1 } 
ia'.bSc'}^ {vi,v 2 ,v 3 } 
{a,b,c} •+ {u!,U2,u 3 } 



Sande has written the generalized expansion for N having 
r factors by making the definition 



Q r - t 1 t 2 t 3 :..t r 



Using this substitution in (9) and (10) we get 



t ■ ux + u 2 Qi + . 



m ■ (7— ♦ 



r-1 



Q r Q r .! 



u rVi 

vi 

Qr 



We will express the first j terms of t 



as 



f (j) - U! + u 2 Qi «• . . . u jQj-i * 

The Sande-Tukey decomposition of the general transform 
expression uses two identities which result from the algebra 
The first of these is an expression for the generalized 
exponential term; 



Qv. 



k-l 



The second is the generalized expansion for the summation 
on t 



T-l 'I" 1 V 1 
I = I I 

T=0 Ui«0 u =o 

* r 



Combining these results we can get a generalized expression 
for N having r factors 



T-l 

T=0 



t,-l 



x(t) 



vi 



I e(u lr p) 



Uj-O 



e (v, 



t 2 -l 

U2=0 



Q 2 



v 2 



e(v 3 iip-) 



V 1 



e(v r ^ilil) I e(u r Il X( Ul 
'r u =o r 



If we' consider the expansion for N=2.2 we see that one stage 
of complex arithmetic is avoided in the inside summation. 
For the case where N has 3 factors, ABC, the interior summation 
is extremely simple; however, we are faced with shifting factors 
in the subsequent summations which require sine and cosine 
terms to be evaluated. The shifting factors take on a complex 
configuration as the number of summations is increased. Pro- 
gramming is simplified by using the 3 factor expansion in all 
cases and letting C equal 2 or 4 so that we may avoid a factor 
of 2 or 4 complex operations. 
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INTRODUCTION 

The IBM-TSX System was designed for an IBM- 1800 operating 
in a real time environment as a process controller. The Aerospace 
IBM- 1800 is used primarily as a post flight data reduction system 
interacting witn telemetry ground station equipment. This demands 
the full interrupt facilities of the sytem but in a batch processing 
mode of operation such as offered by the TASK stand alone type 
system. As a result the NIMS Monitor System was developed to 
combine the features of the process and non-process modes of 
operation into a general mode of operation in which the full interrupt 
and peripheral facilities of the machine are available to the 
active application program under execution. 

A schematic representation of the Data Reduction computing 
complex is shown in Figure 1. The IBM- 1800 is a 32K core size 
machine with 2 microsecond cycle time. Also attached are 2 
magnetic tape units, 3 disk drives, a 1442 card/reader punch, 
a. 1443 printer, a 1627 plotter, and a 1816 typewriter-keyboard. 
This system services the telemetry playback equipment through 
a Telemetries T-670 PCM decomutation computer and a special 
purpose display terminal called a Waveform Display Analyzer. 

The prime mission of the 1800 system is high speed data 
logging from telemetry tapes of either analog or digital data 
plus driving the attached graphical display and recording 
equipment. 
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IBM - 1800 System Configuration 




2. 



COLD START CONSIDERATIONS AND MODIFICATIONS 



The initial endeavor to provide a more convenient monitor system 
for the data reduction programs involved at attempt to return to a one 
card cold start procedure. In addition, it was considered desirable 
that an automatic cold start of restoring the systems skeleton from 
disk be accomplished between jobs instead of a task reload. 

A decision was made that defective cylinders on a disk pack 
would not have to be handled by the cold start routine. This decision 
was based on the fact that there have been no defective cylinders on 
any of 12 disk packs used in the computer center in 18 months of 
operation. If a disk pack does develop a defective cylinder, it will 
be discarded or refurbished. 

This allowed the LDR-Cold Start Load Card Program and the 
CLD-Systems Cold Start Program to be rewritten in very simplified 
form such that a one card loader would initiate a complete core 
loading cold start from the systems disk. 

The NIMS- TASK program was also modified such that the 
action of pressing the immediate stop, start buttons on the console 
would cause the same action as loading the cold start card. This 
stipulates that core storage not be storage protected at any time. 
Figure 2 presents a table of the modifications required to provide 
the new cold start capability. 
3. PROCESS/ NON PROCESS CONSOLIDATION 

In performing the analysis of what type of system would be most 
desirable, the general conclusion pointed toward a non-process offline 
TASK system with a full interrupt processing capability at that level. 
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if Modified Programs fir Co!^ Start 



LDR - COLD START LOADER PROGRAM 

• EXTENSIVE MODIFICATIONS 

• 27 16 WORDS 

CLD - COLD START PROGRAM 

• EXTENSIVE MODIFICATIONS 

• E8 16 WORDS 

TASK - SKELETON PROGRAM 

• MINOR MODIFICATION TO TASK RESTORE 

ROUTINE 



The NIMS monitor system was founded as a TASK offline system 
with certain protective features in the core-load builder modified 
to allow the use of interrupt service subroutines, the masking 
subroutines, and timer subroutines with non-process coreloads. 
Thus, because TASK is the basic building block, the TASK 
support programs such as TRACE, CORE DUMP, DISK DUMP, 
etc. , are available with this system. 

The core-load builder is constructed such that the special 
purpose operation codes associated with different type core-load 
builds are separated in their table by delimiting constants. For 
example, a process type operation code could not be used in 
anything but a process coreload. It was a very simple thing to 
change those delimiters such that the operation code tables for 
the process and interrupt coreload functions were included in the 
non-process operation code table. 

The final modification negated the test in the non-process 
supervisor for the type of coreload being executed. Figure 3 
represents a table of the modifications necessary to provide the 
consolidation of process and non-process coreload functions. 

TRACE DEVELOPMENT 

The TASK utility programs have been included as a subset of 
the NIMS monitor system. All utility programs were considered 
adequate for debug tools by the data reduction programmers with 
the exception that it was felt that the TRACE output was too 
difficult to interpret. 
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Table of Modifications to Consolidate 
Process and Nonprocess Fursctii 



1. CLB - CORE LOAD BUILDER PROGRAM 

• MINOR MODIFICATION TO OPERATIO 
CODE TABLE LIMITS 



2. NPS - NONPROCESS SUPERVISOR PROGRAM 

• MINOR MODIFICATION TO REMOVE 
TEST FOR PROCESS CORELOAD 




This problem lead to the development of inserting additional 
coding in the TRACE routine in TASK to provide a mnemonic format 
conversion for generating the output for the 1443 printer. An 
example of output generated while running under the TRACE 
mode is shown in Figure 4. The prime features of this development 
are a much easier format to read and the calculation of the 
effective address that the instruction operation code will be 
referencing. 

SOURCE PROGRAM FILE STORAGE SYSTEM 

Significant effort was expended in providing a source program file 
storage capability in conjunction with the NIMS monitor system. 
This capability provides programmers the means for storing 
source language programs for subsequent retrieval during checkout 
activities. The programs are stored on tne file such that alter 
cards could be read through the card reader to modify the source 
program before the assembler performs its function. This activity 
was accomplisned in two pnases. In tne first, the system components 
such as TASK, ASM, FTN, and DUP were modified to accept input 
from magnetic tape. In the second, a series of programs were 
written to generate a systems tape, provide an alter capability, and 
perform a periodic update of the source program systems tape. 

The key to providing the systems routine with the capability of 
accepting input from magnetic tape involved including the coding 
of the MAGT routine in the TASK skeleton and providing a one 
word logical switch in fixed core for interrogation by the input 
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segments of the systems routines. This switch forces the I/O routines 
in the system to read tape drive when set by the non-process 
supervisor after reading a // TAPE card from the card reader. The 
switch will be reset for the I/O routines to read from the card 



It was also necessary to modify each of the I/O routines in the 
assembler, FORTRAN compiler, disk utility program, and the 
non-process supervisor. Since CARDN is included in the NIMS- 
TASK, the coding of CARDN in each of the systems routines was 
replaced with the coding necessary to test the card/magnetic 
tape switch and perform the magnetic tape input operations. 
Depending on the routine, it was necessary as part of the magnetic tape 
input function to convert the card image from tape either back to 
card image format, a special one character right justified EBCDIC, 
or leave in standard two word EBCDIC. 

Figure 5 is a pictorial representation of the NIMS magnetic tape 
system showing how the support programs interface with the systems 
programs to perform a complete job operation. 

The CDTST-Card to Source Program System Tape Program is used 
to place the initial version of a source program on the system tape. This 
procedure involves searching the system tape for the last record, back- 
spacing the tape to prepare for the write operation, and writing the card 
images from the card reader in blocked tape format of 200 cards per 
block. The termination card of the program causes a new end-of-tape 
record to then be generated. 



reader if a / / CARD image is read off of magnetic tape. 
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RELOCATABLE 
PROGRAM IN 
TEMPORARY 
STORAGE 




^CONTROL 




CARDS 
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© 



The ALTER-Source Program System Tape Alter Program has the 
function of allowing the programmers tne capability of altering source 
statements as it is unblocking the program from the source program 
system tape to a scratch tape in preparation for input into the 
assembler program. Figure 6 shows the three data card formats 
that can be used with the ALTER program. The alter function of the 
alter cards is determined by the character in column 72 as follows: 
R means replace tne card image on the source program system tape 

having the corresponding sequence number in columns 77-80 with 

this card image. 

I means insert this card image in front of the card image on tape 
with the same sequence number in columns 77-80. 

D means delete the card images on tape inclusively between the two 
sequence numbers in columns 73-80. If only one card image is to 
be deleted, the sequence number should be punched in columns 73-76. 

The output magnetic tape on drive is generated in 80 character 
EBCDIC format for direct input into the ASM system assembler. This 
is triggered by a / / TAPE card following the last alter card in the 
card input stream. 

After the assembler has finished with the assembly process and 
stored the relocatable program in temporary storage on the disk, the 
next record is read from the tape input stream on drive 0. This 
record is a // CARD image transferring control back to the card 
reader. The program that has just been assembled can then be 
executed or permanently stored on the disk. 




11 
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Sample Alter Card Format 
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The third program associated with the NIMS tape assembly 
procedure is UPDAT-Source Program System Tape Periodic Update 
Program. This program will utilize submitted alter decks as input 
to generate an updated version of tne source program system tape. 
The programs that were modified by tnis run will be resequenced 
on the new source program systems tape. 

SYSGQ - NIMS PROTECTION PROGRAM 

Early in the operation of tne TSX system, a programmer 
inadvertently destroyed the system on the disk to a degree tnat it 
was necessary to do a new system generation from cards. It 
was decided at this point that tne system disks would be copied 
on magnetic tape with a capability implemented to restore the 
disks from this tape. 

The SYSG0 program was written to provide the disk to tape 
operation, the punching of a self-loading execution card, and the 
subsequent tape to disk regeneration process. The first step 
of the execution of the program involves storing the first 12 
locations of core in a table for the regeneration phase of the 
program. A split-binary self loading card is then punched that 
is used to load the system skeleton and the SYSG0 program into 
core from magnetic tape during the regeneration phase. Next 
core storage from location through hex 3000 is written out on 
tape. This record contains the system skeleton as well as the 
SYSG0 program. As a final operation the system disks are then 
copied to magnetic tape 20 sectors in a record. 



After a SYSG0 tape has been generated, it can be saved for 
later use to restore new systems disks. This is accomplished by clearing 
core storage and loading the self-loading card punched by the disk to 
tape phase of the program. The loader card causes the first record 
from the tape containing the system skeleton and the SYSG0 program 
to be read into core storage starting at location 12. The final 
instruction on the card is a branch to the appropriate entry point 
in the SYSG0 program that will copy the remaining tape records 
on the systems disks. Figure 7 presents a schematic representation 
of the operation of this program. 

MINOR SYSTEM DEVELOPMENTS 



Additional features have been added to the NIMS monitor system 
that extend the performance of the system or provide a more simplified 
operating procedure. 

The standard ASM Assembler Program has been replaced by an 
IBM released MACRO Assembler Program called MASM. This has 
been found to be a powerful tool for the programmers providing 
extended programming capability. 

The NIMS-TASK program was modified to provide the programmers 
and operators with the ability to execute stored coreloads by typing 
in the program name on the typewriter. This activity is initiated by 
pressing the console interrupt button with no sense switches on. The 
typewriter will request that a 5 character program name be entered 
through the keyboard with the following message: 

TYPE IN FIVE CHARACTER PROGRAM NAME 
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forage Prooodmro 



DISK REGENERATION PHASE 
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REQUEST DISK 
DRIVE AND 
PACK LABEL 
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When the name is typed, the NIMS-TASK program generates a 
card image to execute a fixed coreload and transfers control to the 
non-process supervisor. The non-process supervisor with the 
card image in its input buffer then performs a FLET search and 
proceeds to execute the coreload. 

The data reduction programmers requested that a current 
date be printed on the assembler and compiler output listings. This 
was implemented in NIMS-TASK and the non-process supervisor 
such that any control message printed by NPS would have a date 
loaded from the fixed area of TASK included on the end of the line. 
The date is stored in TASK by executing a program called DATE 
where the date is requested by the typewriter as follows: ' ^ 

TYPE IN DATE -DD MMM YY- 
When the day, month, and year are typed in, the program converts 
them to print codes and stores them in the fixed area of TASK. 

SUMMARY 

Every attempt was made in the implementation of the NIMS 
monitor control system to provide the data reduction programmers 
and operators with a convenient system oriented to telemetry data 
reduction. This endeavor has been accomplished and further 
activities will be directed to additional facilities for the convenience 
of the programmers and operators. 
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Investigation of Abnormal Operating Conditions 



A few short years ago many of our data processing system error recovery 
procedures were hardware dependent. That is to say the program hung up 
until the hardware circuitry recognized that the condition causing an error 
had been corrected or reset. 1401 systems stopped with a Process, Reader, 
Punch, Printer, or Tape error-indicator lamp on the operator's console, 
directing the operator to inspect a particular device. 

The reader may indicate a "reader check" (i.e. , card read or checked in 
error), "punch stop" (i.e. , card misfed or jammed), or a tape unit may no: be 
ready. The system could not continue until the operator had corrected t'.io 
cause of the error by refeeding the error card, correcting the feed problem, 
or making the tape unit ready. 

The point I'm trying to illustrate is that the problems were fairly obvious and 
the improper restarting of the system difficult when viewed from todays' s 
environment. 

The design, architecture, and flexibility of System /360 makes this type of 
operation impractical. Error information is presented to the program and 
further visual indications to the operator are dependent on the system control 
program. Since, for example, a system /3 60 Model 30 can run under BPS, 
BOS, TOS, DOS, OS, emulators, or a user written control program, an 
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operator must be knowledgeable of the specific system in use. Let me give 
you an example. A model 30 operator has just observed the system in the wait 
state. Hitting the start or interrupt button produces no effect on the system. 
What has happened? There are not outward error indications! No messages 
have been printed on the typewriter! If BPS or an Operating System is con- 
trolling the system certain bytes of main storage will contain a coded 
message indicating the reason for the halt. Only prior knowledge will 
direct the operator to display this area. Furthermore, interpretation of 
this data can be in zoned decimal, binary, or packed format. 

Basically there are 3 main areas a system can be divided into. The "Central 
Processing Unit" (CPU), or heart of the system; the "Channel," over 
which the CPU communicates with I/O devices; and the "Input/Output 
Units." A fourth area could be "Non Operational Units." These may be 
off line units or devices never installed on the system. Any address not on 
the system will result in Non-Operational Status if used. 

I would like to define the. effect of problems in each of these areas. , .- 

Central Processing Unit errors are caused by bad data on data busses or in 
key registers of the CPU and result in a logout via system micro -programming . 
From 12 to 25 6 bytes of information and status at the time of failure are re- 
corded and the new machine check PSW is loaded. Appropriate indicators are 
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set in storage by the control program as operator information and the 

a 

system is placed in the wait state with all interrupts disabled Channel 
failures are errors that occur during communication between the CPU and 
an I/O device. This could happen if the CPU signals a device and the 
device fails to respond within a specified time. A programmer requesting 
a unit to read or write no data could also result in a channel error. Channel 
failures may result in a micro-program logout with appropriate indicators 
set in storage as operator information. This area should be investigated 
closely as failures can result from improper channel programming. 

Input/Output errors pertain to specific devices (tapes, disks, reader, 
punch, printer, etc.) and always result in a sense command being issued 
to that unit. This sense operation will transfer up to six bytes of inforrnati' 
from the unit to the CPU for analysis by the control program. Error recovery 
will be performed dependent on the error. Tape read errors result in a back- 
space and reread with a TIE if possible. Each time this sequence has been 
performed eight times, a tape cleaner routine is executed. The tape is 
backspaced 3 records and forward spaced twice. This runs the record over 
the tape cleaner blade removing any excess oxide. After 100 rereads are 
performed, it is considered an unrecoverable I/O error and the job may be 
cancelled. Tape write errors result in a backspace, erase and rewrite. 
Disk read or write errors cause a retry unless a defective track is found. A 
defective track will cause a seek to an alternate track and a read or write. 
Unit record devices require operator action at the device and a proper 
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response to the programming system. The operator should examine the 
sense information for the cause of error. 

If the job had cancelled under the Disk or Tape Operating System ail the 
pertinent information will be logged on the typewriter; however, it must be 
decoded with respect to the specific I/O unit to obtain all the meaningful 
information. The same error on BPS or BOS would result in the wait state. 
Unit record type devices will require operator intervention. Restart pro- 
cedures require the proper reference SRL. Operating guides for all devices 
should be available to operators . 

Proper maintenance of materials can save countless hours and headaches. 

Initialize all disk packs before use. Notice that the plant has affixed 
a label indicating tested bad tracks. These tracks should have alternate 
tracks assigned during your initialization. This is necessary because 
surface analysis performed prior to shipment tests the complete usable 
surface for each track. Subsequent use of these tracks will be unpredictable 
and dependent on individual. R/W head tracking on each disk drive. 

Tape must also be properly initialized, even in an unlabeled shop. Tapes 
are always checked by logical IOCS to ascertain if label information 
exists. An improperly initialized tape my result in a permanent tape read 
error and cancellation of your job. This can be avoided by writing a TM 
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at the beginning of all unlabeled tapes . Remember the seven or nine 
track tape marks can only be read error free on their respective drives. 
Mark all reels plainly for use on one tape drive (i.e. , seven track 
Drive 183). Operators should clean tape drives as often as necessary 
to minimize tape errors. 

Card decks should be given proper care. Plastic edged decks are best 
in high usage circumstances. Master decks should never be used except 
for reproduction. This is your best protection against card decks that ran 
yesterday and program check today. Be certain you have an IBM card 
gauge and check for punching off registration periodically. A high inci- 
dence of reader checks or one card that cannot be read also require check 
with the card gauge. 

What methods should be used during isolation of an abnormal operating 
condition? This depends on a great many variables; however, a certain 
basic attitude should prevail. Kow can I obtain the maximum useful and 
meaningful error data for analysis by the programmer or IBM engineer? 

The first point should go without saying, but all too often goes unheeded. 
Stop! Determine what the system will tell; you may have to ask (i.e. , 
display appropriate core locations). Remember, a hardware failure does 
not necessarily produce a red light indication. On DOS or TOS only by 
displaying Main Storage locations 0-3 can it be established that an error 
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has occurred. On BPS and a BOS hex location X '32' contains the error 
indicator. What action the operator should take is described in the operator's 
manual. If a machine or channel failure has occurred, a logout will take 
place. The system is placed in the wait state to allow the operator to 
run SEREP. The "System Environment Recording Edited Printout" program is a 
stand-alone card deck that will interface with IBM control programs, determine 
the type error that has occurred, and print out all pertinent information and 
status of the system at the time of failure. This program will be provided by 
your Customer Engineer at installation. SEREP will print out from 12 to 25 6 
bytes of logout area (dependent upon CPU type), old PSW's, new PSWs, 
CAW, CSW, GP regs, Floating Point Regs. , or sense information. 

It is especially useful when a customer engineer is not on site. It is 
essential that all operators be versed in rocognizing a SEREP request. A 
core dump or re-IPL at this time will destroy any information of value. 

SEREP will pinpoint invalid use of channel programming, use of non-opera- 
tional devices, and bad I/O devices. All SEREP runs should be saved for 
analysis. 

Only after the operator has collected all meaningful data for subsequent analysis 
should a run be attempted. This is particularly important on intermittent 
failures. 

If a SEREP run was not requested a core dump should be taken. Save all. 
core dumps, console logs, output, input, program decks . Documentation 

-2 
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to the extent of recreating the failure is best. 

Try to isolate the culprit by changing devices, restoring disk packs, 
using other card decks, or if possible run the job on another system. 

Of course if the operator believes a hardware system failure exists, he 
should follow the normal procedures for notifying his customer engineer. 
If the problem seems to be in programming all the pertinent data should 
be returned to the programmer. 

Experience indicates the best approach when system time is available 
is to rerun a failing job under the supervision of the person or persons 
responsible for analyzing the problem. This quickly determines any 
procedural or operating problem and gives you first-hand knowledge 
of the events leading up to a specific problem. 

Many times what one person feels is irrelevant is the key to the problem. 
If your programmers after .thorough analysis conclude that IBM's programs 
are not meeting specifications or a new release level produces a change in a 
program's operation, contact the applicable IBM representative. 

If your programming system is not at a current level, check the latest announ 
ment letters. The problem may be fixed by updating your system. Many 
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problems are now fixed with product temporary fixes (PTF's). These are 
patches or modules available to correct problems before they can be 
included in an official release of the programming system. If no PTF 
is available Field Engineering will determine a temporary fix or circum- 
vention and submit an APAR to resolve your problem. 

A meeting with both your hardware and software customer engineers at 
installation time to establish adequate PM schedules and error recording / . 
and reporting procedures can insure a maximum system availability. The 
smooth running of today's system requires quick and accurate diagnosis of 
hardware, program, or operational problems . 

Our best solution to this is continued co-operation:" 
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ABSTRACT 



In April 1966, a subcommittee of USASI Task Group X3«4,2 was established to 
investigate the standardization of ?L/I« Since that time, two working committees 
have established with explicit charters: 

Group Is The Resolution of the Language PL/I 

and 

Group II i Formal Definition of PL/I 

This paper deals specifically with the work of the committee on Formal Definition 
and its relations with the definitional task forces within IBM. This paper will 
discuss the techniques of definition as proposed by the committee, the uses to which 
the definition is to be put and the implications of the work of this committee on 
the standardization of other computer languages, 

A familiarity with P L/I is not presumed « 



The need to program digital computers in abstraction as opposed to the 
subjective wiring of boards has lead to the development of a variety of program- 
ming languages o These non-natural communication systems are classified, broadly 
according to their orientation toward the human user or toward the moronic 
detailed instructions of a machine,, Whereas the human desires a language akin to 
that which is either his mother tongue or one of the other artificial languages 
with which he has been associated, many of our current languages have been developed 
from machine dependent codes towards these desires and have not yet reached the 
half way point Although there are many proponents of the concept of ultimately 
using natural language as the means of describing a computational (or more 
specifically, a trans forma t. tonal ) process, these forms of input suffer from two 
major defects: a) they are verbose, and b) they suffer from many possible ambiguous 
contextural translations Further, we currently do not thoroughly understand the 
syntax and semantics of natural languages 3 In any case, mathematical notation 
(language) has developed over the past few hundred years in spite of the existance 
of natural language „ 

Existing analyses of programming language, such as found, for example, in 
the ALGOL 60 report [1], place emphasis on the syntactic form of the concepts 
and definitions o In contrast, the approach being proposed by the subcommittee 
X3o4»2C2 of the USASI, concentrates on the role of constituents of a language as 
commands or instructions when the program is executed in a machine This implies 
that the programming language is to be considered in relation to a machine, be 
that machine actual or abstract Classical abstract machine models such as 
Turing machine or finite automata, which are obvious bases for the definition of 
language semantics, lack many of the salient features of an objective situation 
which are relevent to the description of the execution of a program,, For example, 
Turing machines lack the random accessibility of current memories, thus throwing 
the burden of (say) table look up to the wiles of the definer* 
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Conversely, some models imitate machines more accurately but are unsuited 
to the general definition required in the specification of a standard „ For 
example, if there exists an executer (compiler, interpreter, or translator) for 
PL/I on a particular machine, then that executer is de facto definition,, In 
paraphrasing De* Carte (I think a therefore I am) a compiler can be said to execute 
and therefore to define On che other hand, an assembly lising of a compiler 
cannot be said to constitute a nationwide standard and in any case contains many 
algorithmic processes of analysis^ recognition and (in particular) generation 
which are irrelevant Further as the state of the art compilation advances, 
it must be expected that the efficiency of compilation and the optimization of 
the generated code will improve ^ thereby presenting an improved definition^. 

However, a compiler transforms an input in one non-natural language to 
another non-natural language which is not a standards Further only the execution 
of this target language can reveal the semantic nature of the input (or source) 
language o We must, therefore, raise the question as to how a natural language 
description of the syntax and semantics fills the basic necessities of a specifi- 
cation* In particular, a definition which may be used as a standard must 
possess the following qualities s 

- it must be rigorous 

complete 

- it must display structure 

underlying concepts 

- it must distinguish between language defined elements 

implementation defined 

elements 
undefined elements 

Current experience with ALGOL 60 [1] and FORTRAN [2] shows that the natural 
language descriptions of a programming language do not meet all those require- 
ments « Ambiguities exist in the current documentation standards of these 
languages which have been inserted as a result of the use of a natural language 
as a descriptor o Witness the list of "trouble spots" reported by Knuth [3]o 

ci36 
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Similarly, natural language specifications tend to overlook the possibility 

of the effect of executing a procedure in which the values of certain entities 

fall outside the domain of the specification,, That is, current specifications 

only define the semantics of a program that exactly fits the task for which it 

was designed o For example, the FORTRAN specification (sec 7 l 2 lo3) states: 

"7olo2 lo3 Computed GO TO Statement* A Computed 
CO TO statement is of the forms 

00 TO (k-^t o o o o c , k ^) , i 

where the k's are statement labels and is iL an 
integer variable reference,, See 10„2.8 and 10,3 
for a discussion of requirements that apply to the 
the use of a variable in a computed GO TO statement 

Execution oi this statement causes the statement 
identified by the statement label to be 
executed next, where j is the value 3 of 1^ at the 
time of the exeuction " 

However j no mention is made of the action to be taken when the value of the integer 
variable is outside this range „ Yet this sitxiation can occur during execution 
without protection or detection at compile time In my own shop fl we use four 
different versions of FORTRAN which treat this problem of values outside the 
range of definition in different manners 

If a description is to demonstrate the structure of a language both at 
the syntactic level and the semantic level, then the interrelation of both 
the elements of the language must be fully expanded r or example, consider the 
interrelation of COMMON, DIMENSION and EQUIVALENCE in FORTRAN „ A verbal ex- 
planation of this interaction is verbose and contains many its , elses . buts and 
excepts, the subject phrases of which are not readily accessible On the other 
hand, an algorithm for specifying the interrelation of these statements is 
definitive though lacking the ease of readability. 

Yet, why should a specification be generally readable? In no way can we 
consider that specification or a standard to be a teaching instrument and further, 
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a specification or standard must be aimed at the designers and inspectors 
of standards and not the general public* For example, a building code is 
couched in the standard terms of the civil engineer or the building inspector 
and is not of general concern to the person using (say) an auditorium* If 
such users have questions regarding a building code, then they rely on the 
technical ability of the experts* 

Thus a standard specification which is based on the technological tools of 
the profession is a valid specification* However, in the computer industry 
there are insufficient people trained to have an understanding of the theory of 
programming to be able to act as the experts for the general user. This is 
the fault of our educational system and cannot be used as a deterrent to the 
development of standards based on the state of the art* 

The purpose of a standard definition exceeds the bounds of merely forcing 

a minimal conformity upon implementers* A definition should also act as an 

information system to answer such questions ass 

"Is •••••••• a legal part of the language?" 

"What happens if ?" 

"If this element is added to the language, does it create any 
ambiguities?" 

"Does the compiler provided by the manufacturer conform to the 
standards?" 

Thus in some respects a standard must be an information retrieval system, 
in other respects, it needs to be a model translator and executer * However, there 
is a point beyond which this standard cannot pass, that is, there is a limit 
to that which can be thought of as closing the credabllity gap* For example, 
arithmetic must be considered to be implementation defined and thus outside the 
scope of the definition* However, the questions, "What does 0*1 + 0*2 mean?" 
can be answered as "0*1 + 0*2 is an expression, where 0,1 and 0*2 are real 
decimal fixed point constants and + is the infix operator representing the operation 
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of addition," Then the nuestion "What is the result of evaluating the 

expression 0,1 + 2?" might be "The result of evaluating the expression 

o l + 2 is a representation of 0«3 to the same base and scale of the operands 

and the precision of the greater of the precision of the operands „" Thus a 

binary machine which evaluates the expression and produces a result of 0^2988 

will be conforming to the standard to the same extent as a decimal machine 

producing the result 3 c Thus having considered these arguments „ the task 

group reported [4]s 

"It is our belief that with the development of syntax 
diiected compilation as a standard technique s the 
formalization of PL/I will aid in any standardization 
that takes place not only by providing a document 
for people to read but also by providing part of the 
actual input to be used in the construction of a 
PL/ I compiler o While we recognize that an implementer 
may choose not to build his compiler in this way, we 
at least will simplify matters for those who make this 
choice a " 

This approach was not based on an abstract concept but as an acceptance in part 
of the formal definitions of P L/I developed by IBM at Vienna, Austria and 
Hursley 9 England, Both definitions are based on the concept of a PL/I machine 
in which an infinite memory is organized as a combination of tree structures and 
push down lists The execution of a program is defined in terms of the changes 
in the state of the PL/I machine The two PL/I machines developed by Vienna 
and Hursley are not identical w that for Vienna being closer to an actual machine 
than that of Hursley c Fundamental ly e the two schemes are similar to the schematic 
shown in Fig„ 1 

The primary portion of the definitions is a Concrete Syntax which specifies 
the legal statements of the programming language and is based on Backus Naur Form 
plus special nomenclatures for repetitions, grouping and options 9 and a notation 
for specifying lists For examples 
program s \ m external-nrocedure 

major-prefix-list ss » i !(major*pref ix-element [ ,major-pref ix element] „ «, d ) i K «> „ 
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delete-statement : : » DELETE { # file option • key-option, [event-option] }; 
Both definitions use this concrete syntax as a specification for constructing 
legal elements of the language and as a guide for the analysis of the concrete 
text (input strings) • The reversibility of this syntax is still in question and 
eventually it may be found necessary to replace the single definition, by a 
syntax for the construction of legal elements of the language and another as a 
guide to the analysis of concrete text. 

Given a concrete text which satisfies the rules of construction and which 
has been analyzed to show the syntactic functions (components) , the input must be 
analyzed next to show the underlying structure. Since much of the structure 
is evident from the order in which syntactic components are recognized in the 
analyzer, the tasks of analysis, recognition and generation may be combined into 
a single transformational process, the target of which is an intermediate language 
In the Hursley definition, this intermediate abstract text is a tree-like structure 
in which all Implied declarations, elements resulting from default conditions 
and functional relationships are added so that the text is complete. This target 
text is described by an abstract syntax which is itself a tree-like structure. The 
translator, which accepts the concrete text and under the direction of the 
concrete and abstract syntacti develops the abstract text, performs several tasks: 

- parses the concrete text 

- removes redundancies (punctuation, comments, etc) 

- reorders internal procedures, declarations, etc 

- expands attributes 

- makes all names fully qualified 

- inserts declarations for labels and entry names 

- forms a complete set of attributes for each identifier by observing: 

- defaulting rules 

- contextual declarations 
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- built in functions 



- implicit declarations 



Once a valid abstract text has been created, the semantics of this text 
are demonstrated bv the use of an interpreter vrtiich shows the changes in the 
state of the t»l/I machine The interpreter uses as its input s the abstract 
text and the data sets., 

Although the authors of these definitions are to be complimented on the 
completion of a magnificent task, certain snecial requirements and di r f <:vr< r>(v. n-t- 
opinion necessitate the reorganization of these definitions to conform with 

h" need to develop a standard, Initially, it was recognized that if a formal 
style of definitional standard is to be proposed then it must be based on a standard 
notationai method applicable to all languages „ In particular, it was felt that 
the concept of specialized abstract machine such as V L/I machine, or a FORTRAN 
machine, or an ALOOL machine, could not be proposed as the standard but uiffering 
constituent of each specification,, Instead, a standard machine should be 
dev. o^ed which would be capable of "executing" any programming language -and 
dissociated data sets. Further, if a standard is to be capable of answering 
questions regarding both the syntax and semantics of a language, the system must be 
capable of not only analyzing input strings but also synthesizing strings given 
(say) an abstract text. 

On the premise that a standard should be implement able as a software system, 
the task group chose to propose that the intermediate text should be a canonic 
program which is closely associated with the syntax of the input text The 
schematic of the proposed standard is shown in Fig 2« This schema utilizes 
several mechanical (algorithmic) components which are to be common to all language 
definitions and which, therefore, must be developed as part of the tools of 
standardization f: Therefore, the descriptors of the language being defined must 
be developed and standardized themselves 
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The concrete and abstract (or canonical) syntacti can be expressed in a 
modified Backus Naur form, or at least some variant of which is expected to 
be acceptable as a standard The actual syntacti metalanguage being developed 
for the X3 4 2C2 task group, is a linear machine readable metalanguage of which 
the following statements are examples (see the previous IBM specifications) : 
<program> external procedure 

<major prefix list> ■+> 0,I*<major prefix element > 0,I*<major prefix element>:)) 

<delete statement> ■* DELETE (3,3* [<file option | <key option> | (0,1* event 
option>) ]) 

where the enclosure of me tacomp orient names in braces eliminates many of the 
problems of ambiguity in the metalanguage* The parenthesis groups are of the 
general form of an implied DO list in a FORTRAN input/output statement with the 
variation that the limits of the repetition precede the list and the increment is 
always unity— thus the construct <n>-*(l,3*A) means that the metareisult <n> may 
be formed from 1 to 3 concatenations of the terminal A, The same metalanguage 
may also be used to define the syntax of the canonical intermediate text and it 
is further anticipated that a transformational grammar can be developed which uses 
the same basic nomenclature « 

However, the 1 terminology of the analyzers, synthesizers and the executer 
cannot be readily expressed in Backus Naur Form though some variant of AMBIT [7] 
would seem to be appropriate « The "execution" of the input text using the 
schema shown in Fig, 2 is merely one approach to the problem of definition. An 
alternative technique would be to define a fundamental language in detail 
according to Fig« 2 and then to define transformational grammars on of her 
languages to transform them to this fundamental language „ The choice of this 
fundamental language could be one of the biggest political problems to face the 
data processing section of US AS I. 

In fact, if PL/I is all it is purported to be, then it is the obvious funda- 
mental languages However, the growing band of advocates of APL (or Iverson 



Notation) have a candidate for this position which has already been shown 
to be adequate for the formal description of a machine [5] and hence should 
he adequate as the target language of syntax directed translator 

The type of linear executer described by the Hursley and Vienna definitions 
&:ad by definition executer of X3 A 2C2 or the translator described in the 
previous paragraph , cannot adequately describe a language which is self 
modifying or self generative However, a feed back loop from the "executer" or 
"interpreter" to the syntax analyzer will solve this problem,, 

On the face of it, a definition executer does not appear to be as efficient 
as a standard compiler for the straight forward task of recognizing an input 
structure,, This conclusion is based on the premise that no matter how efficiently 
the specification is designed, the analyzer portion of the executer will spend 
some considerable percentage of its time exploring blind alleys „ Further ^ the 
keys of string recognition may be camouflaged beneath the wealth of associate 
syntax 9 every element of which must be verified before even a preliminary recog- 
nition can be made. For example, the first three characters of each BASIC 
[6] statement are a key to the type of statement following. As another example, 
a compiler implementer has at his disposal certain machine dependent information 
which he may utilize to improve the efficiency of the recognizers In particular, 
the sorting order of characters permits the testing of characters in a relative 
manner so that a binary tree can be built, in which the length of the maximum 
branch (representing maximum number of comparisons to be made in recognizing 
a character) is a minimum,, The maximum tree branch needed in a USASI FORTRAN 
compiler for the recognition of a keyword is five, A syntax directed translator 
does not have this ability and thus must chain through a linear sequence of 
alternatives till the list is exhausted. That is, for example, to recognize 
that the character 1 is not an element of the alphabet requires only five compari- 
sons using a binary tree search in a compiler (Fig a 3) but 26 comparisons in a 
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syntax directed analyzer* Under these conditions, a definition executer may 
never replace the specialized compiler and with the given purpose of definition, 
the speed and efficiency of execution is not in competition* As programming 
languages become more permissive , the task of defining a language in prose will 
become more difficult and there will be a corresponding increase in the complexity 
of a compiler* However, the definition execution and syntax directed translator 
can handle this expectation* 
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S'^ARY 

In this paper, I have tried to explain the concept of a language definition 
baaed on the techniques of syntax directed **mpiling and translation. Whilst 
a standard definition of a computer language may be incomprehensible to the 
majority of the programming community of today, those who are concerned with 
implementing systems conforming to the standards will be members of the 
minority (by definition) • A definition executer as described herein will not 
only define the syntax and semantics of a language but also outline the trans- 
latory techniques of a compiler. In comparison, a building code contains 
parallel partitions whereby the design criteria and techniques of construction 
are specified. 

Programming languages are intended to be languages of precision. Yet we 
are relying currently on languages of imprecision to specify the syntax and 
semantics of those same programming languages. If for no other reason than for 
consistency and perhaps to maintain the image of the industry , the formal 
definition of language will repl&c :he current prose definitions. 
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A "SMALL" OS SYSTEM 



As Described to Wade A„ Norton (1125) 
By Max L. Allen (1164) 



Rust Engineering (1164) of Birmingham, Alabama, and Pittsburgh, 
Pennsylvania, a company which specializes in engineering design and 
construction, has recently become a division of Litton Industries. 

Their work includes (1) Design and construction of process 
mills — paper mills being a good example, (2) Renovation of office 
buildings, (3) Maintenance and construction work for government, and 
(4) Design work for government, including some launch facilities at Cape 
Kennedy. 

Rust has offices at Calhoun, Tennessee; Montreal, Quebec, 
Canada; Vancouver, B. C, Canada; Brussels, Belgium; and Mexico City, 
Mexico — in addition to their principal offices in Birmingham and Pittsburgh. 

Rust employs about eight hundred people each in the Birmingham 
and Pittsburgh offices; and, even though the mix in the jobstream is 
quite different at the two installations, they are able to generate a 
single OS system to meet the requirements at both places. 

In Birmingham the mix is approximately 65%-357o engineering 
vs. business data processing, whereas in Pittsburgh the ratio is about 
15% to 85% (in favor of commercial work) . Some of the work in Birmingham 
—quite properly classified as engineering — is engineering management 
information, rather than design or analysis. 

In Birmingham it is possible to schedule very little of the 
work because report periods vary for different contracts. Near the end 
of a report period, they likely are making several runs with their 
management info tools. 

In Pittsburgh one of their big jobs is labor costs, which is 
often run several times a day. 

However, staffing is not too different in the two localities, 
with each employing about ten or twelve analysts and programmers. In 
Birmingham they have two machine operators; in Pittsburgh, four for two 
shifts, therefore .employing two per shift just as in Birmingham. 

On the other hand, there is a distinct difference in the number 
of keypunch operators — due to the difference in the amount of input 
data. In Birmingham three keypunch operators are employed by the computer 
center, whereas in Pittsburgh (where the mix is 15%-85% commercial) the 
accounting department has ten to twelve keypunch operators on its payroll. 



You may ask — and properly— why I present this paper. I am 
the first to agree that the real author is Max Allen of Rust's Birmingham 
computer center. 

Unfortunately, he has been unable to make either the Cincinnati 
meeting or this one. In Cincinnati this paper was presented by title 
to the OS Committee. That group agreed that the subject matter is far 
more appropriate to the full S/360 Project. Thus it appears on the 
agenda for today. 

Rust's computer department exhibits a certain rugged individu- 
alistic spirit — of just the sort we want displayed by COMMONers — to dig 
into the uncharted and build there something of real value. 

And, having mapped the previously unknown, they have demon- 
strated to the fullest a second trait we wish of all COMMONdom — the 
willingness to share with others their knowledge, their system, and, 
indeed, test time. 

I can truthfully say that we would most likely be in some stage 
other than the final one of conversion from a 1620 system to S/360-40 OS, 
had it not been for Rust's pioneering of OS and their willingness to 
share with us the fruits of a then hard-won prize. (My only reluctance 
at making the last remark is that it might be construed in some quarters 
as implying that this paper is in payment of a moral debt. That is not 
the easel At no time has Rust ever implied that somebody owed them 
anything; furthermore, this paper was requested by your former OS 
Committee chairman, Mrs. Barbara F. Young.) 

And certainly, Rust's work deserves reporting — OS is for the 
MOD 30 and MOD 40, and both COMMON and IBM need to be told this fact. 

The remainder of this paper fills in the details as told to 
me by Max Allen of the Rust computer center (and observed by me in the 
course of Southern Services' conversion efforts) » 

Max's position at Rust is as the Number One man on the systems 
and applications side of the activity, and in the absence of the manager 
he assumes these functions, also. 

This manager, who was sweating the dollars and cents of OS 
pioneering while Max perspired over the bytes and bits of the work, is 
Bill Mylius. Bill is in charge of computer facilities at both Birmingham 
and Pittsburgh. And, while this story is basically one of implementation 
and told by Max, the policies reported in the telling of the story are 
Bill's. 

Rust tried DOS and it did not give the flexibility they needed. 
This was especially true with respect to structuring of programs larger 
than one core load. CALL LINK under DOS FORTRAN helps, but it does not 
solve things. In reality it creates greater rigidity* 
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Another initial consideration in the choice of OS is that the 
Project Management program and ICES (MIT) were both written to run under 
OS. Later developments of ICES push it out of 64k and only further 
justify the choice. 

Core requirements for OS of slightly less than 16k were evalu- 
ated against both the 6k DOS requirement and the 10k needed for DOS -2 
with fixed scheduler partitions. It was decided, Max said, that the 
additional core devoted to OS more than paid for its dedication in a 
more powerful system, "particularly since the linkage editor is so 
flexible in how one may structure his program." 

Still another item which influenced Rust's decision at the 
time was that they were enthused over the prospects of using fullblown 
PL1. Their experience to date has been that it is clumsy in both compile 
time and run time, but very easy for the programmer. At the time 
(November 1966), PL1 was not supported under DOS. It is known that PL1 
has been and is continuing to be improved. That as yet they have not 
gone to it as their primary language has not caused them to regret their 
choice of OS. 

In fact, they would make the same choice today — OS over DOS — 
which they made more than a year ago. (And, I might add, today they 
would have a lot more support from IBM in its implementation.) 

Rust considers the following as disadvantages of OS or, more 
properly, as part of the price paid for the more powerful system: 

1. There is lots more to learn about OS than about any other 
system for driving a 360. 

2. OS can do lots more, but this flexibility also creates problems 
of choice. 

3. To applications programmers, JCL presents great problems. 
There are no clear-cut logical patterns to follow.. 

4. Operator requirements are not easy for any method of driving 
S/360. It is a complicated machine. But with OS, the training 
of operators is considerably more difficult. 

5. Rust paid the price, also, (in November 1966) which IBM's lack of 
field knowledge^ about OS cost. IBM Birmingham was reluctant 

to send their people to school. Rust's CE worked on OS when 
he had nothing else to do, and A PAR answers were such as, "It 
looks like you got a bad tape." Rust started to SYSGEN on 
November 8, 1966, with Release 6. They obtained their first 
running version on December 23, 1966, with Release 7. In 
between there was much effort expended— 'mostly by Rust people — 
before IBM finally imported a man from outside the local office. 
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Actually IBM did not really begin to support OS in Birmingham 
until two Mod 40 installations — Alabama Power Company and 
Liberty National Life Insurance Company — were being implemented,, 
(Southern Services, Inc., (1125) whom your speaker represents, 
has merged its operations with Alabama Power, an affiliated 
company.) It turned out that much of this trouble, which took 
more than a month to find, was caused by the Linkage Editor 
which was losing a CSECT out of the nucleus. 

6. When Max went to OS school in Cincinnati, there was not a single 
course offered by the New Orleans region. Because of the aero- 
space industry, some training in OS had been offered in Huntsville, 
but this was not under region sponsorship. In Max's opinion, 
the course at Cincinnati was a good course. Since that time, 
IBM has been schooling their people regularly and offering 
courses on a broader geographical basis. The know-how is 
available now; the marketing emphasis for OS with the Mod 30 
and Mod 40 is lacking. In both Max's and my opinion, this is 
something IBM should correct. 

Among the things they bought were 

1. Improved Job Management. 

2. Better Data Management. 

3. More powerful Linkage Editor. 

4. Identical systems for Birmingham and Pittsburgh even though 
the hardware and addressing differed slightly. In Birmingham 
their punch is a 1442 addressed at 00A, while in Pittsburgh it 
is a 2540 addressed at 00D. 

5. Under OS, Rust has found that it is almost impossible for an 
operator to lose control of OS by a misstep at the console. 

6. Combining items 2 and 3 has made it possible to catalog programs 
and data and put them on disks for exchange between Birmingham 
and Pittsburgh. 

7. Without the power of OS to put programs elsewhere than on the 
system residence volume, Rust's programs would have required 
multiple system residence packs a la the 1620. 

Rust did not run extensive timing tests, because they were 
not felt necessary in weighing OS against DOS. Enough was done (with 
programs which constituted a large part of the workload) to bear out 
the already known generality that OS FORTRAN (E) compile-link and compile- 
link-go were both superior to their DOS equivalents. They used only 
FORTRAN because this was the only language in which they felt sufficiently 
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proficient at the time. They have since used COBOL some, too, while 
they wait for a better-performing PL1. They checked compile- link using 
a Plant Material Thermal Balance program, which is their biggest job. 
They found that OS did the job in 8 minutes compared to 30 minutes for 
DOS. Using a Steel Stack Design program, they found a compile-link-go 
advantage of 22 percent while using OS. 

When they started, all they wanted was enough system to do 
some testing (and it was the hardest to come by). In the interval 
December 1966 to December 1967, Rust generated five releases. SYSGEN 
is now easily done in a manner that suits Rust f s needs better than the 
cookbook method described in the SYSGEN manual. However, this is stated 
as a plus for Rust's experience and not as a criticism of following the 
book — which procedure will get your OS for you. 

You can have a basic system for about 14k of core storage. 
This will include PCP (the sequential scheduler with all options tran- 
sient instead of resident), support for a reader, printer, punch, one 
disk (for system), and four tapes. It would include the access methods 
BSAM, QSAM, and enough BDAM to access programs and compilers. It would 
not include a timer, indexed sequential access methods, nor direct access 
methods for applications data sets. 

Rust's system requires 3F08^5 bytes (or 16,136-^g). To be 
exact, it is slightly more than 16M bytes, but slightly less than 16K 
bytes where K = 1024 = 2^ „ In this amount of storage, Rust provides 
for PCP, interval timer, three disks, no tapes, two punches (as described 
above), a 2501 card reader, and a 1403 printer. They have the standard 
access methods QSAM, BSAM, BP AM, BISAM, QISAM, and BDAM They have 
resident SVC entries and trace table entries. If IBM ever supports just 
a plain timer, Rust will take it over the interval timer and thereby 
save a little more core. 

The full direct access method, the indexed sequential access 
methods, and the trace table entries were included, because Rust believes 
they buy enough in supporting FE work to justify their inclusion. 

At the moment, Rust can do the work required of their system. 
But, looking to the future, they see more core needed, greater processor 
speed, and more devices to support. And they look upon their experience 
with OS as a great boon to future growth. A possible first step might 
be the addition of a second selector channel, if spooling under MFT-2 
is shown to give reasonable performance at the 65k level. 
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Working title of the paper: The 1620 as a Data Collector or 

Software, the Crutch Hardware Boys Lean On 

Author: Guy A. Gallaway 

Address and User code: Sacramento Peak Observatory 

Sunspot, New Mexico 88349 
User #5053 

Position: Programmer 



Time requirements: 30 minutes 

Special Equipment: Projector for 3 1/4 by 4 inch glass mounted 
(lantern) slides. 

Level: Intermediate 



Machine: 1620 II was used, but the presentation will be for 
general information . 



Abstract: The paper will cover the data collection methods 
used at the Sacramento Peak Observatory. The principle reasons 
for designing a computerized data collection system were: 

1) Improve existing methods which used summary punches. 

2) Gain experience and insight into problems associated with 
data collection in preparation for third generation equip- 
ment . 



The paper will also cover the roles played by the. programming 
staff in this type of operation. Namelv, software as a diagnostic 
tool for the hardware boys in developing data reduction/collection 
instruments, and software as a useful and flexible tool for the 
research scientist. 



Three methods for data collection and reduction bv computer have 
been tried. 



1) On line, one point at a time, testing each point for 
parity and structural errors and storing it on the disk 
before the next point is generated. 

2) On line, a record at a time, locking the source device 
out until the data has been tested and stored. 

3) Off line, using 7 track incremental tape recorders, with 
testing and reduction being done during slack times. 
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1620 DATA COLLECTION 



(or, Software, a Crutch That Hardware Boys Lean On.) 

This paper will describe, in varying degrees of detail, three 
different methods of data collecti on. Each of these methods was 
developed and used at the Sacramento Peak Observatory, Sunspot, New 
Mexico. The Observatory is part of Air Force Cambridge Research 
Laboratories and performs basic research in solar physics. Two of 
the methods were on-line to a computer and the third, still in use, 
used an incremental tape recorder as intermediate storage. 

The overall goal of the project was to experiment and compare 
the use of real-time collection with remote collection on an inter- 
mediate device, such as mag tapes. We originally intended to continue 
this experimental approach with our third generation equipment before 
committing ourselves to either method. But now it looks like we will 
be doing a combination of both. 

To this end we felt we should implement these systems on an 
established machine. In this way both the hardware and software 
people could, and did, gain experience and insight into the problems 
involved. 

The immediate goals were to develop a more reliable system and 
establish a complete operating system. An earlier method made use 
of a summary punch and was very unreliable. We also wanted to try 
and develop some systematic procedures for handling this type of 
data, and to have available a standard set of reduction/utility 
routines for processing the data. But this approach usually meets 
with opposition from the individual scientist who wants a "tailor- 
made" system for his project, the definition of which will usually 
change every few months. Since we are planning on implementing 
the same devices on newer machines, this attitude means that we are 
faced with the propsect of never-ending systems development. We 
have found that after the initial development an equal amount of 
time will be spent in making changes to meet specific desires. 

The goals of the system were always being jeopardized by 
frequent modifications in " mid- stream" . From the time we started 
to implement data collection, up until now (last week) there have 
been continuous changes to the system. These cover the full range 
from the data format to reduction procedures. None of the systems 
were developed as a unit and then examined and evaluated. This 
lack of a commitment to full development has been demonstrated to 
waste considerable manpower and machine time. 

The source of the data was photographic films, typically 
filtergrams and spectrograms, of various solar phenomena. We 
use a scanning microphotometer to read the films. Film densities 
are converted to a 3- digit decimal number and sent to the computer 
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or the tape recorder. The computer used was a full 1620 II with 
binary features. The two on-line systems employed the paper tape 
channel for data transfer. We have an on-line plotter, but no 
conflict occurs since the plotter uses the write paper tape in- 
struction and collection uses the read paper tape instruction. 
Termination of the data was done by sending a record mark on the 
End of Line (EOL) line. 



SYSTEM #1 

The first method was the only one requiring a real time 
response. The characteristics of this system were: 

1. A l-2-2'-4 BCD format. 

2. One data point at a time transmission. 

3. Packed data. 

4. Termination of the data string by a counter control. 

This strange BCD form, 1-2-2' -4, was a "left-over" from the 
previous system that used a pulse counter with this format. This 
added the problem of encoding the data to the normal data handling 
problems. This was the first instance of a hardware problem for 
which the software provided the solution. Figure 1 defines the 
formats used and shows how the paper tape lines were used. A 
minimum of 20% of data handling time was devoted to the encoding. 
The data was stored on the disk in one sector blocks of 31 points. 
Only every other jpoint was flagged making the data appear as 16 
6-digit words. (12312312 3123) 

The coice of two points per word of data was made to achieve 
minimum disk storage and still insure disk compatabi lity with 
Fortran. That is, given a fixed point word size of six, and the 
array IDATA dimensioned at 16, the statements, RECORD (J) IDATA 
and FETCH (J) IDATA, will reference one sector of 96 digits. 
The unpacking of the data was done in a Fortran subroutine. 

The maximum data rate, 20 points per second, left ample time 
available for the programming required to handle each point. Total 
programming time requirements using the longest encoding routine, 
worst case, took only 2640 microseconds. The greatest time component 
was disk revolution time, worst case conditions being 44 mils. 
Figure 2 gives a detailed description of the timing involved. 

Originally there was to be an ID number sent as the first data 
point. But in order to speed up the process of implementing the 
system we used the ID number as an input argument between the main- 
line Fortran program and the collection program. This ID number was 
then the first point of each disk block, making each block 32 points 
long. 
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Termination was to be done three ways. Two of these were 
similar, both using sense switches. The setting of one switch 
would indicate that the collection had been completed normally and 
reduction should begin. The other switch would indicate an operator 
error and for the current collection to cease and re- start. The 
third method, and the only one implemented, was by having the user 
specify in his Fortran program the number of points to be collected. 
This number was another input argument for the collection routine. 

What turned out to be the most significant advantage in getting 
the system going was the "off-the-shelf" hardware. Our engineers 
are "time shared" with the whole Observatory. They are responsible 
for building and maintaining a very large number and variety of 
complex equipment. And as frequently happens under such circum- 
stances the person that yells the loudest gets his work done the 
fastest. So by having working hardware we were able to complete 
the system sooner than if the hardware had to be built. 

The disadvantage of this system was its slowness - not only 
the data rate but the over-all system. Considerable time was 
required in the Fortran programs to get the data from the disk and 
unpack it. This, however, is a familiar story to programmers, 
minimizing storage at the expense of execution time. 

One problem in the early stage of development was the 1620. 
We had learned from IBM that each character signal should be main- 
tained 10+ microseconds. The first try was a signal of 12|a, which 
got "lost" in the CPU. A diligent pursuit of the signal with 
scope and probes convinced the EE's of the soundness of their de- 
sign. The data left their black-box and entered the computer. To 
them it was unfortunate that the program, or programmers, couldn't 
find the data. Even elaborate overlay and dump routines failed to 
completely convince them that the data wasn't reaching core. 
Finally, the extension of the signal to 20u's maintained the charac- 
ters long enough for them to reach core. We were then able to 
collect data. 



SYSTEM #2 

The second on-line system used new hardware and software. 
The new hardware was designed and built by our own engineers. We 
wrote new but similar software. This system had several entirely 
new features; 

1. BCD compatability . 

2. Transmission of records of data. 

3. A source generated 6- digit ID. 

4. Variable data rates. 

5. Starting the source device with the computer. 

BCD compatability solved the encoding problem and cut down on 
the required programming. 



By allowing the transmission of a record of data we had to 
limit the total number of points collected in each record. We 
decided to use 1/2 of the available core, 24,000 digits. This was 
equal to 4000 data points three digits long, each point being 
converted to a six digit fixed point number. Conversion to the 
six digit size was done in the collection program. Considerable 
time was saved by eliminating the slow unpacking routines in 
Fortran. We still limited the size of the data blocks on the disk 
to one sector of 16 points. 

The hardware generated ID number was an aid to the file 
management problem. It was to be the first six digits of the data 
string. The number would be chosen by the user and selected on 
thumb wheel switches, and read out of a register. 

Also, a control was installed to allow the user to digitize 
at a variety of rates from 1 to 100 points per second. 

The collection of variable length records required the "locking" 
out of the source device. This was to be done by allowing the 
device to send only upon receipt of a computer generated signal. 
The Exponent Overflow indicator was chosen as this trigger. This 
would require turning the Exponent Check light, EXP CK, on for 5 
mils immediately preceeding the read instruction. 

The software was quickly written and debugged due to the 
similarity with the previous system. The construction of the 
hardware took considerably longer, mostly due to the manpower 
problems mentioned before. And before the system was operational 
there were more than a few changes in definition. 

The first problem was the EXP CK light. The 5 mil signal was 
not long enough to turn on the data source. A testing routine was 
quickly written to vary the time and 250 mils was determined to be 
the shortest reliable length. 

The next problem was the ID number. The ID register read out 
too slowly. For any data rate greater than 20 points /second the 
first few data points would be lost. Designing a faster read-out 
didn't completely solve the problem, so the ID number was moved to 
the end of the data string, the last six digits. 

Moving the ID solved the problem of losing points but caused 
another problem, which is still in the system. For some undetermined 
reason the ID number is frequently, in half or more of the cases, 
seven digits long. In the majority of these the extra character 
appears to be the seventh, last, digit. But there are many times 
when the first and second digits are the same, both flagged, making 
the first character appear to be the extra one. But with either 
case there are six good digits which can be selected, by programming 
for the ID. 
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Here were two hardware problems, ID generation, and device 
control which required a software solution for implementation. 

In the early development of this system there were random 
parity problems. Several test programs were written to display 
these characters and examine them with the binary instructions. 
There were also structural errors in the data, that is, one of the 
three digits would be dropped. The design was changed and these 
problems reduced. (They still occur, infrequently, and are a good 
indication of some temporary problem in the hardware.) 

We were still having problems with the EXP CK trigger and 
decided to use the computer logic of the read instruction. With 
the able help of our IBM CE this was done, and with considerably 
less effort than expected. 

SYSTEM #3 

This was now compatible with tape recorder design and the 
recorder was hooked into the system. 

The person collecting data could nov*/ work, at any time, us ing 
the computer or the tape recorder. This was, operationally, a 
better policy since the computer wasn't tied up for long periods 
collecting data. The tapes were reduced in the evenings and during 
the day when the computer wasn't in use. The same software handled 
the data tapes by using the read paper tape instruction. 

With the installation of the tape recorder we were also able 
to reduce binary tapes from a different source. By this time we 
had learned not to write a full software package before the hardware 
had evolved into its final form and was debugged. Two short routines 
were enough to reveal various failures in the hardware. These 
problems were similar to the other system, lost points and digits, 
and a new one, a data point in the middle of the ID information. 

USE OF THESE SYSTEMS 

The second system was modified for one user to eliminate the 
use of the disk. He collected a constant 500 points. The collection 
program was changed to format the points and place them directly 
in the COMMON area of Fortran. This was a considerable time- saver 
for his application and he was able to collect about 7 million 
points in one month. This was the only production work done using 
either system. 

Most users wanted their data plotted as soon as possible to 
determine if they were operating the equipment correctly. Since 
the Fortran plotting was pretty slow we wrote a short machine language 
program to read the data and plot it directly from core. As the data 
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is defined as ranging from 0-999 no scaling -was required. The 
result was plotting done four times faster than in Fortran. We 
were now inspired to try and hook an oscilloscope onto the computer 
for even faster plotting. We even went so far as to develop pro- 
grams to convert the plot commands into a continuous string of 
digits corresponding to the pen commands. In this way plotting 
was done by dumping core, with a pen command coming every 10 (j. . 
Manpower shortages prevented the hardware boys installing the 
scope . 

The amount of time required in developing utility and debug 
routines for the hardware was greatly underestimated. Until the 
hardware worked, a programmer had to be available every time the 
hardware was tested. One four hour session resulted in the 
writing of five short machine language programs. In addition 
an immeasurable number of dump routines were composed and executed 
at the console typewriter. I do not mean to cast aspersions on 
the hardware fellows. Their basic design has proven very reliable. 
It was a lot of fun? and very satisfying, to build the system into 
a usable tool. The point is, both the hardware and software people 
must work closely together from the very beginning. It is not 
unreasonable to expect the consulting of some computer oriented 
person when designing any data system, since the data will eventually 
reach a computer. 

Our error was in planning on just writing the software package 
and not budgeting for time to write the programs to debug the 
hardware. They could have done it with scopes and a bread-board, 
but a more reliable "unit" is developed when both sides are in- 
volved in the operation. 

Of the three methods we used, the best, in my opinion, was 
clearly the use of the tapes. The procedures the user goes through 
to set up the source device are usually very time consuming. And 
he will often be reducing more than one type of data at a time, 
requiring additional set-up time. When the computer was on-line 
it would often be used less than 50% of this set-up time and 
never used fully. Production runs could often be done only in large 
blocks of time, four or more hours. This forced the user to use the 
computer at night. And more importantly, the on-line system 
required someone familiar with the machine and programs to be 
available at all times. (Typical reason for this was the user would 
send too much data and clobber the program, but he still wanted to 
save the data in core. This and similar problems required the 
presence of a programmer during data collection.) 

The advantages of the tape system were mostly operational. 
The user was only competing with other microphotometer users, 1 or 
2 people at most and frequently no one, instead of many computer 
users. The scheduling for the microphotometer was done by the 
day instead of by the hour as for the computer. The user needed 
only to know how to run one machine instead of two. And most 
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importantly, more efficient use was made of the computer. During 
the set-up period the user could use the computer in 5 to 15 minute 
blocks as required to test his data and operating procedures. 
During production runs the bad records can be identified in advance 
so the programs will ignore them, a considerable time saver. Also 
the reduction of the tapes can be done by a competent computer 
operator, with the special cases (extra long records) being handled 
by special programs, without loss of data. 

These reasons would be less important with a machine capable 
of handling foreground /background programs, but cannot be entirely 
dismissed. Generally speaking, the data would still be placed on 
an intermediate device such as a disk or tape before reduction. 
Under such circumstances careful consideration must be given to 
each method. Cost is not a small factor. For a few collection 
operations the extra cost of a computer hardware to do the job 
would be proportionally higher, when compared to individual devices 
and controllers at each site. But for a large number of such 
applications, which can be mutliplexed, the cost is reduced for 
each device, when done with a computer. 

Another important consideration is site locations. Transmitting 
data at high rates and control of collection devices over large 
distances is still pretty expensive. This tends to force the col- 
lection instruments to be located near the computer. When this is 
impossible then the on-site system using an intermediate device is 
one solution. 

One way of evaluating a system is by asking, "Would you do it 
again?". There is no doubt that we would, and gladly. The one 
production run mentioned before, with 7 million points collected, 
would have been impossible to do under the previous system, in less 
than four months, if at all. 

We now know, more clearly, what to expect of the basic collection 
routines, what to expect them to do and what not to have them do. 
Our new computing equipment will be in use a minimum of five years, 
probably much longer. Those of us in programming are desperately 
hoping that the research scientists will completely develop a 
working system before changes are even discussed. The single biggest 
factor in extending the development time of these systems was changes 
in the basic definition of what the system would be. 

The only advice I would offer to anyone considering doing this 
type of work with a General Purpose machine is to see it through to 
the end, and then evaluate the whole system. Even if you have 
unlimited manpower and time to continue re-doing the same thing, it 
is much easier to work with a system which has a few, well-defined, 
operational peculiarities, than to re-educate every user every time 
he uses the system. 
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- Programs for Inverting a Large Matrix on - 
a Small Machine 
by •< . 
T. E. Bridge 

In figure 1, we have plotted, time to invert a matrix, versus the size of 
the matrix. We have plotted results for two programs, one using partitioning, and 
the other using sequential files. The same form of test matrix was used in all 
cases. Double precision arithmetic (17 digits) was used, 

Size of Matrix 25 60 120 

Partitioning Method (Table 2) 

Time Minutes 2 19 115 

RMS Error % 0.000 .356 1.252 

Sequential Files (Table 3) 

Time Minutes 3 29 213 

RMS Error % 0.000 0.000 

Direct Access Files (Table 6) 

Time Minutes 4 29 231 

RMS Error % 0.000 0.000 0.001 

In this paper, we are presenting three programs: 

Table 2 To invert a matrix by partitioning the maximum size is 352. 

Table 3 To invert a matrix using sequential files. The maximum size is 300 

Table 6 To invert a matrix stored on disk. The maximum size is 300, 

Two other programs that were used in testing the above three programs are 
also given: 

Table 4 A program to build a large matrix for testing. 

Table 5 A program to multiply the test matrix by its invert, and then 
compare each element with the corresponding element in the 
unity matrix. The RMS error is calculated and published. 
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Description of Partitioning as Used by the Program in Table 2 ^ 

The following formulas, that we use in Table 2 to partition the matrix, 
are given in "Linear Algebra", by G. Hadley Addison-Weekly Publishing Company, 
1961 on page 109. 

A large matrix may be partitioned into four smaller matrices. Let 
a, b, c, d — represent four small matrices arranged like this to form a large 
matrix: 

a b 
c d 

Note that a and d are square matrices; while b and c may not be. 

Let the invert of the above matrix be represented by: 

A B 
C D 

Let: e = the invert of d. 

The following equations may be used to find each partitioned piece of 
the invert : 

A a (a - bee)" 1 ^ 
B = -Abe 
C » -ecA 
D s e - ecB 

The program given in Table 3 uses these equations to find the invert of 
a large matrix. We had only 5K bytes of storage — 629 double words left over 
with the partitioning program in core. Since 100 words are required for data 
handling, we find that the large matrix must be partitioned down to a -- 23 x 23 
before it can be inverted. So, four levels of partitioning would be required to 
invert a 352 x 352 matrix. 

The levels of partitioning required are: 

Matrix size 23 46 92 184 352 

Levels required 12 3 4 

We found that the minimum amount of partitioning gave the shortest amount 
of run time when using this progrma. In other words, it took 20% longer to invert 
a 100 x 100 matrix using 4 levels rather than the required 2 levels of partitioning. 
We don't really know what would be the optimum amount of partitioning on a larger 
machine. 
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TABLE 1 LISTING OF PROGRAM 0003 

0004 
0005 

THE FOLLOWING PROGRAM IS INCLUDED ONLY TO TEACH THE METHOD OF OPERATION 0006 
USED IN IHfc PROGRAMS LISTED IN TABLES 2 AND 3 0\J^ 

0008 

C THIS PROGRAM WILL SOLVE N SIMULTANEOUS EQUATIONS 0009 

C 0010 
Nl = N + I 0011 
DO 1 K = i,N 0012 
F = X(K,K) 0013 
DO 1 J= K , N 1 0014 
3 X(K,J)= X(K,J| / F 00li> 
DO 1 I = i,N 0016 
IF (I-K) 2,1,2 001/ 
2 XU,J) - XU,J) - X(K,J) * XU,K) 0018 
1 CONTINUE 0019 
END 0020 

0021 

STATEMENT i ABOVE IS THE HEART OF THE PROGRAM. IT IS IN THE INNER LCOP 0022 
AND IS EXECUTED N ** 3 TIMES 0023 

0024 

EQUATION K IS THE KEY EQUATION 0025 

0026 

THIS IS DONE IN STAiEMENT 3 . 0028 

0029 

2) IN STATEMENT I , EVERY TERM IN THE KEY EQUATION IS MULTIPLIED BY 0030 
X(I,K) AND THEN SUBTRACTED FROM THE CORRESPONDING TERM IN EQUATION I 0031 
THIS WILL GENERATE A ZERO IN COLUMN K. EACH SWEEP OF THE MATRIX WILL 0032 
GENERATE A COLUMN OF ZEROS IN COLUMN ( K ) EXCEPT FOR THE TERM ON THE oCj* 
DIAGONAL WHICH WILL BE 1.0 . 0<^ft 
BY PERFORMING A SERIES OF VALID OPERATIONS (NOT CHANQInQ THE EQUALITY) 0035 
WE GENERATE THE UNITY MATRIX. THE ANSWERS WILL THEN APPEAR IN THE LAST 0036 
COLUMN . 0037 



TABLE 2 LISTING OF PROGRAM TO INVERT A LARGE MATRIX STORED ON 0040 

DISK USING PARTITIONING 0041 

0042 

//#fTION CATAL 0043 

VlASE BJPL$04,S 0044 

// EXEC FORTRAN 0045 

COMMON N3, N4 f N5, N6 , J I M , NM , I T , I S , N J , NP , NC , NX 0046 

C N3 IS A WORK FILE UN DISC 0047 

C N4 IS A TEMPORARY SEQUENTIAL FILE 0048 

C N5 ISA SEQUENTIAL FILE FOR STORING MEMBER INFORMATION 0049 

C N6 IS A DISC FILE IN WHICH MATRIX IS STORED 0050 
C JIM IS THE SIZE uF THt SMALL MOSAIC OF WHICH THE BIG MATRIX IS NAQE 0051 

C NM IS THE NUMBER OF MEMBERS 0052 

C IT IS FILE TO WHICH PROGRAM WILL RETURN 0053 

C IS WILL CAUSE DIAGNOSTICS TO BE PRINTED 0054 

C NP IS PAGE NO 0055 

C NC IS NO OF COLUMNS IN BIG MATRIX 0056 

C NX IS NO OF CCLUMNb IN COMPRESSED MATRIX 0057 

DEFINE FILE 12 ( 1600, 200, U f I 2 ) 0058 

DEFINE FILE 13( 800,200,0,13) 0059 

DOUBLE PRECISION X (529) 0060 

IF(NX - 3)1,1,2 0061 

1 CALL T3$l ( NX, 1,X) 0062 

3 CALL LINK (05) 0063 

2 IF(NX-46) 4,4,5 0064 

4 CALL T 3 1.11 (NX, 1,X) 0065 
GO TO 3 0066 

5 IF(NX-92 ) 6,6,7 0067 

0CALL TB$12( NX, 1,X ) 0068 

GO TO 3 0069 

7 IF(NX-ld4) 8,8,9 0070 

8 CALL 18*13 (NX, 1,X ) 0071 
GO TO 3 0072 

9 IF(NX-352) 10,10,11 0073 

10 CALL TB$14(NX, 1,X ) 0074 
GO TO 3 0075 

11 WRITE (3,100) 0076 
CALL EXIT 0077 

100 FORMAT ( 20H MATRIX TOO LARGE ) 0078 

END 00 79 

/* FEB 0080 

// EXEC FOR I RAN 0081 

SUBROUTINE TB$1(N,NC, X) 0082 

DOUBLE PRECISION X(23,23),F 0083 

COMMUiNi ixi3, N4, N5, N6, NX 0084 

13 = 1 0085 

NP = NC + N - 1 0086 

DO 13 I = 1,N 00 8 7 

K = NC + I - 1 0083 

CALL DATA (1,1,X,I3, NC, NP, K) 0089 

13 13= 13+ 23 0090 

DO 1 K = l f N 0091 

IF (X(K,K) )2, 1,2 0092 

jtfF = 1.00/ X(K,K) 0093 

%P X(K,K) = .1D1 0094 

DO 3 J = If N 0095 
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/* 
// 



X(K,J) = X(K,J) * F 

DO 1 I * ljrN 

IF ( I-K) 4,1,4 
F = X( I,K) 
X( I,K) = O.DO 
DO I J = 1,N 

X(I,J)= X(I,J) - X(K,J) * F 

CONTINUE 
NCI = NC-1 

& N -1 



1»N 
I 

( 2,1,X,I3, 

23 



NC, NP, K ) 



NP * NC 
13 = 1 
DO 14 I = 
K = NCI + 
CALL DATA 
14 13 = 13 + 
RETURN 
END 
TEB 

EXEC FORTRAN 

SUBROUTINE DAT A { JIM, JOE, A, 13, NR1, NR2, NO 
DOUBLE PRECISION A(529) , li 100) 
COMMON N3, N4, N5, N6 
IF(N5) 31,30,31 

WRITE(3,32) JIM, JOE, 13, NR1, NR2, NC 

CONTINUE 



30 
31 
32 



12 
13 
14 



10 



15 



FORMAT </6l8/) 
NF = N6 
NB = 

GO TO (1,2,3), 

NB =2 00 
NF = N3 
CONTINUE 



JOE 



IF(M-ME) 14,13,13 
LF = LE 

READ ( NF * M ) Z 
GO TO (6,7) , 
DO 10 L = LS, 
Ail y~-Yn.T — 
1 = 1 + 1 
GO TO 33 
DO 15 L = LS, 
III) = ATI) 
I = I + 1 



JIM 
LF 



LF 



0096 
0097 
0098 

oMo 

0102 
0103 



0104 

0105 
0106 
0107 
0108 
0109 
0110 
0111 
0112 
0113 
0114 
0115 



0116 
0117 
0118 
0119 
0120 
0121 
"0122 
0123 

m 

0126 
0127 



NK = NC*4-4 


0128 


NRB = NR1 -1 + NB 


0129 


NRE = NR2 - 1 + NB 


0130 


1 = 13 


0131 


LB = MOD ( NRB , 100) ♦ 1 


0132 


LE = MOD(NRE, 100) + 1 


0133 


ME = NK + NRE/100+ 1 


0134 


MB = NK + NR8/100 ♦ 1 


0135 


DO 33 M = MB, ME 


On 36 


LS = 1 


0137 


LF = 100 


0138 


IF ( M-MB ) 11,11,12 


0139 


LS = LB 


■ ' " ~ — error 



0141 
0143 



0T44 
0145 
15T4F~~ 
0147 
0148 

as- 

0151 



WRITEINF'M) Z 0152 

33 CONTINUE 0153 

IF{N5) 42,41,42 0154 

Ol J = 13 + NR2 - NR1 0155 

WRITE (3,100) ( A ( K ) , K = 13, J ) 0156 

100 FORMAT ( 1P10D13.6) 0157 

42 RETURN 0158 

END 0159 

/* TEB 0160 

// EXEC FORTRAN 0161 

SUBROUTINE TOill (N,NA,X) 0162 

DOUBLE PRECISION X (23,23) 0163 

(ML = N/2 0164 

NU = N - INL 0165 

ND = NA + NU 0166 

CALL TBSKNL, ND, X ) 0167 

CALL 1 B $ 7 ( N , MA, X ) 0168 

CALL T B VI ( NU , N A , X) 0169 

CALL TB$8(N,NA,X) 0170 

RETURN 0171 

END 0172 

/* TEB 0173 

// EXEC FORI RAN 0174 

SUBROUTINE TB*7(N,NA,X) 0175 

DOUBLE PRECISIUN X ( 176, 3 ) 0176 

NE = N A & N - 1 0177 

NL = in* / 2 0178 

NU = i\ - NL 0179 

OND = NA £ NU 0180 

NU1 = NU - 1 0181 

C W2 = B * C 0182 

Kl = i 0183 

DO 3 K = iM D , N E 0184 

DO 1 L = 1,NU 0185 

DU 2 J = 1,NL 0189 

1 X(L,3) = C.DO 0186 
C D IN (2) 0187 

CALL DATA ( 1 , 1 , X , 1 77 , N D , N E , K ) 0188 

C B IN ( 1) 0190 

CALL b AT A ( 1, 1,X, 1,NA,ND1, J+ NQ1 ) 0191 

DO 2 I = 1,NU 0192 

2 X(I,3) = X(I,3) &X(I,1) * X(J,2) 0193 
C (3) IN w2 0194 

CALL DATA (2, 2, X, 353, 1 » NU , K J ) 0195 

3 Kl = Kl ♦ 1 0196 
C A = A - W2 * C 0197 

DO 6 K = N A , N D 1 0198 

C A IN (3) 0199 

CALL DATA ( 1, 1,X, 353, N A, ND 1 , K) 0200 

C C IN (2) 0201 

CALL DATA ( 1 , 1 , X , 1 77 , ND , NE , K ) 0202 

DO 5 J = 1,NU 02( > 3 

C W2 IN (1) 0204 

g\ CALL DATA ( 1 , 2 , X , 1 , 1 , NU , J ) 0205 

1# DO 5 I = 1 ,NU 0206 

5 X( 1,3) = X ( I , 3 ) - X( J,2) * XU, 1) 020/ 



C (3) IN A 

6 CALL DATA ( 2 , 1 , X , 3 53 , N A , ND 1 , K ) 

RETURN 
END 

/* TEB 

// EXEC FURTRAN 

SUBROUTINE TBi>8 (N,NA,X) 

DOUBLE PRECISION X(i76 t 3) 

NA1 = NA - 1 

NE = NA + N - 1 

NL = N/2 

NU = h - NL 

NO = i^A 4 NU 

ND1 = ND - 1 
C B = -A * in 2 

Kl = i 

DO 3 K = ND, ,ME 
DO 1 L = 1,NU 

1 X(L,3) = O.DO 
C \riZ IN (2) 

CALL DATA ( 1 , 2 » X , 177, 1 , N U , K 1 ) 
DO 2 J = 1,NU 
C A IN ( 1 ) 

CALL DAT A { 1, 1,X, 1 , NA , ND 1 » J+ *vAl) 
DO 2 I = 1, NU 

2 X(I,3) = X ( I f 3 ) - X ( 1,1) * X (J , 2 ) 
C (3) IN B 

CALL DATA (2, 1,X, 353, NA, ND 1 , K ) 

3 Kl = Kl + 1 
C W2 = D * C 

Kl = 1 

DO 4 K = NA, ND1 
DO 5 L = 1,NU 

5 X(L,3) = O.DO 
C C IN ( 2 ) 

CALL DATA ( 1, 1,X, 177, ND, NE, K ) 
DO 6 J = 1,NL 
C D IN ( 1 ) 

CALL DATA ( 1 , 1 , X , 1 , ND, NE , J + ND 1 ) 
DO 6 I = 1, NL 

6 X ( I , 3 ) - X(I,3) ♦ X ( I , 1 ) * X(J,2) 
C (3) IN W2 

CALL DATA ( 2 , 1 1 X , 3 53 , 1 , NL , Kl) 

4 Kl = Kl + 1 
C C = - W2 * A 

DO 7 K = NA, NCI 
DO 8 L = 1,NL 

8 X(L,3) = O.DO 
C A IN (2) 

CALL DATA ll,l,X,177,NA,NOl, K) 
DO 9 J = 1 , NU 
C W2 IN (1) 

CALL DATA ( 1 , 2 , X , 1 , 1 f NL , J ) 
DO 9 I = 1,NL 

9 X ( I , 3 ) = X(I,3) - X ( 1 , 1 ) * X { J , 2 ) 
C (3) IN C 



0208 
0209 
0210 
0211 

02 

0213 
0214 
0215 
0216 
0217 
0218 
0219 
0220 
0221 
0222 
0223 
0224 
0225 
0226 
0227 
0228 
0229 
0230 
0231 
0232 
0233 
0234 
0235 
0236 

8 

0239 
0240 
0241 
0242 
0243 
0244 
0245 
0246 
0247 
0248 
0249 
0250 
0251 
0252 
0253 
0254 
0255 
0256 
0257 
0258 
0259 
0260 
0261 
»2 
3 



1,X,353,ND, 

NE 



( i , 1, X t 177,NA,ND1, 

i , NU 



/* 
// 



D = D - W2 * 
CALL DATA (2, 
DO 10 K = NO, 
D IN (3) 
CALL DATA 
B IN (2) 
CALL DATA 
DO 11 J = 
W2 IN (1) 
CALL DATA 
DO 11 I = 
11 X( 1,3) = X( I, 

(3) IN 
10 CALL DATA (2, 
RETURM 
END 
TEB 

EXEC FORI RAN 

SUBROUTINE TB*14 
DOUBLE PRECISION 
NL = N/2 

- NL 
!N»A ♦ NU 

TB$13(NL,ND,X ) 
T B $ 7 ( N , N A , X ) 
J8il3(NU,NA, X) 
I8*8(N,NA,X) 



NE; , K) 



(1,1,X,353,ND, NE, K ) 



K ) 



(1,2,X,1,1,NU,J 
1,NL 

3 ) - X ( I , 1 ) 

l,X,j53, ND, 



) 

* X( J,2) 
NE, K | 



( N,NA,X ) 
X (25,25) 



/ 
// 



c 



NU = 
NO = 
CALL 
CALL 
CALL 
CALL 
RETURN 
END 
TEB 

EXEC FORI RAN 

SUBROUTINE T B i> 1 3 
DOUBLE PRECISION 
NL = N/2 

N - NL 
N A ♦ NU 

TB$12(NL,NC,X ) 
I8J,7(N, N A , X) 
T 8 $. 1 2 ( N U » N A , X 
T 8 5 8 ( N , IM A , X ) 



( N , N A , X ) 
X (25,25) 



/* 
// 



NU = 
ND = 
CALL 
CALL 

CALL T 8 $» 1 2 ( N U » N A , X) 
CALL 
RETURN 
END 
TEB 

EXEC FORTRAN 

SUBROUTINE TB$12 
DOUBLE PRECISION 
NL = N/2 

N - NL 
NA + NU 

1 B$ 1 1 ( NL , ND , X ) 
TB*7(N, ,*A, X) 
TB$11(NU,NA, X) 
TBS8(N,NA,X) 



( N , N A , X ) 
X (25,25) 



/* 



NU = 
ND - 
CALL 
CALL 
CALL 
CALL 
RETURN 
END 
TEB 



0264 
0265 
0266 
0267 
0268 
0269 
0270 
0271 
0272 
0273 
0274 
0275 
0276 
0277 
0278 
0279 
0280 
0281 
0282 
0283 
0284 
0285 
0286 
0287 
0288 
0289 
0290 
0291 
0292 
0293 
0294 
0295 
0296 
0297 
0298 
0299 
0300 
0301 
0302 
0303 
0304 
0305 
0306 
0307 
0308 
0309 
0310 
0311 
0312 
0313 
0314 
0315 
0316 
0317 
0318 
0319 



TABLE 



LISTING OF PROGRAM TO INVERT A MATRIX STORED ON TAPE 



J03 BJPL$ 
OPTION CATAL 
PHASE BJPL$13,S 
EXEC FORTRAN 

BJPL$ PROGRAM 



TO 



INVERT UP TO A 300 X 3CC MATRIX STORED 
COLUMNWISE IN FILE 12 . FOUR RECORDS ARE USED FOR EACH COLUMN 
COMMON N3» N4, N5, N6 , M IJ , NM t I T , I S , N J , NP , N I , NC 
DEFINE FILE 12 ( 1600, 200, U, IN2 ) 
DOUBLE PRECISION F,G 

D(300,2), DK 300) 
1) ) 



DOUBLE PRECISION C(300), 
EQUIVALENCE (01(1), D(l, 
DIMENSION NF(2) 



17 

21 



16 



^3 

22 



= 4 
= 5 



l.NC 



( C( L ), 
(C(L ), 
(C(L ), 



NF(1) 
NF ( 2 ) 
M = 1 

N =. 2 
DO 14 J = 
J4 = J*4 
READ(N6'J4-3 ) 
READd^ 1 J4-2 ) 
R E A D ( N 6 * J 4 - I ) 

14 WRITE (4) C 
REWIND 4 

READ ( 4 ) ( CI ( L ) , 
REWIND 4 
DO 8 K = 1,NC 
F = D(K,M) 
IF (F) 4,15,4 

15 DO 2 J = 1 , N C 
READ ( N F ( M ) ) (CCD 
GU TO 19 

4 F = l.CO / F 
DO 2 J = 1,NC 

IF (K-J) 16,17,16 
DO 21 L = 1,NC 
C(L) = O.CO 
C(K) = l.CO 
READ ( N F ( M ) ) 
GO TO 22 
CONT INUE 

READ ( N F ( N i ) ) (C(L), 
IF (N5) 23,22, 22 
WRITE( 3, 11 ) J, ( C( I ) 
CONTINUE 
C(K) = C(K) * F 
G = C(K) 
DO 1 I = 1,NC 
IF(I-K) 3,1,3 
3 C( I ) = C( I ) - 
1 CONTINUE 

19 IF (J-K-l) 20,5,20 

5 DO 7 L = 1,NC 
7 D ( L , tM ) = C ( L ) 

20 CONTINUE 



L= 1,100) 
L=101,200) 
L=201, 300) 



L = l.NC) 



L = 1,NC) 



L = l.NC) 



I = 1,NC) 



D ( I , M ) * G 



0324 
0325 
0326 
0327 

0329 
0330 
0331 
0332 
0333 
0334 
0335 
0336 
0337 
0338 
0339 
0340 
0341 
0342 
0343 
0344 
0345 
0346 
0347 
0348 
0349 
0350 
0351 
0352 

of 

0355 
0356 
0357 
3 58 
0359 
0360 
0361 
0362 
0363 
0364 
0365 
0366 
0367 
0368 
0369 
0370 
0371 
0372 
0373 
0374 
0375 
0376 
0377 

03* 



1F(N5) 9,10,10 
9 WRITE (3,11) J, (C(I), 1= 1,NC) 
11 FORMAT (15/ ( IX, 1P10D12.5) ) 

OiO CONTINUE 
WRITE (NF(.M) ) (C(L ), L = i,NC) 

2 CONTINUE 
REWIND 4 
REWIND 5 
L = M 

M = N 

3 N = L 

DU 30 J = 1,NC 
J4 = J * 4 

READ ( NF(M) ) ( C ( L ) , L = 1,NC) 
WRITE (N6« J4-3HCU), L = 1,100) 
WRITE (N6» J4-2UCU), L = 101,200) 
WRITE (N6' J4-1)(C(L), L = 201,300) 
30 CONTINUE 

CALL LINK (05) 
END 

/* TEB 

INCLUDE UVERLAY 

// EXEC LNKtCT 



37? 



0380 
0381 
0382 
0383 
0384 
0385 
0386 
0387 
0388 
0389 
0390 
0391 
0392 
39 3 
0394 
0395 
0396 
0397 
0398 
0399 
0400 
0401 
0402 



TABLE 4 LISTING OF PROGRAM USED TO GENERATE TEST MATRIX 
// OPTION CAT AL 



PHASE BJPLfclO, S 



// 


EXEC 


FORTRAN 




COMMON N3, N4, N5, N6 , J I M , NM , I T , I S, N J , NP , NC , NX 


c 


N3 


IS A WORK FILE ON DISC 


c 


m 


IS A TEMPORARY SEQUENTIAL FILE 


c 


N5 


IS A SEQUENTIAL FILE FOR S TURING MEMBER INFORMATION 


c 


N6 


IS A DISC FILE IN WHICH MATRIX IS STORED 


c 


NM 


IS THE NUMBER OF MEMBERS 


c 


IT 


IS FILE TO WHICH PROGRAM WILL RETURN 


c 


IS 


WILL CAUSE DIAGNOSTICS TO BE PRINTED 


c 


NP 


IS PAGE NO 


c 


NC 


IS NO OF COLUMNS IN BIG MATRIX 


c 


NX 


IS NO OF COLUMNS IN COMPRESSED MATRIX 



DEFINE FILE 12 ( 1600, 200, U, I 2 ) 
DOUBLE PRECISION A( 100,4) 
DO 10 K = 1,400 
10 A(K,1) = O.UO 
N3 = 13 
N6 = 12 

READ (1, 1000) N 5 , I S , N X , ( A ( K , 1 ) , K = 1,16) 

1000 FORMAH2I2, 14, 10A4) 

WRITE (3,1000) N5, IS, NX, (A(K,1), K = 1,16) 
L4 = NX / 100 L 1 
DO 1 K = 1,NX 
DO 2 L = 1,NX 
LK = K * NX - NX L L 
KL = L * NX - NX L K 
A(L,1 ) = LK L 1 
IF (L-K) 3,6,2 
6 A ( L , 1 ) = A ( L » 1 ) * 10. 
GO TO 2 

3 A< L, 1 ) = KL + 1 
2 CONTINUE 

K4 = 4*K - 4 
DO 4 L = 1,L4 

4 WRITE (N6» K4&L) (A(I,L) , I = 1,100) 
IF (Nb) 5,5,1 

5 WRITE (3,1001) K,( A ( I , i ) , I = 1,NX) 
1 CONTINUE 

NM = MCTIME (0) 
WRITE (3,1001) NM 
CALL LINK (IS) 

1001 FURMAT(/Il6/( 2X,10F10.1)) 
END 

/* TEB 

// EXEC ASSEMBLY 
MCTIME START 

USING *,15 

GET I ME BINARY 

LR 0,1 

BR 14 

END 

/* TEB 



TABLE 5 LISTING OF PROGRAM USED TO CALCULATE RMS ERROR WHEN 04< 

INVERTING A TEST MATRIX 04* 

046 

/J%OPTION CAT AL 046 

UPHASE BJPL$05,S 046 

// EXEC FORTRAN 047 

COMMON N3, N4, N5, N6 , J 1 M , NM , I T , I S , N J , NP , NC » N X 047 

C N3 ISA WORK FILE ON DISC 047 

C N4 IS A TEMPORARY SEQUENTIAL FILE 047: 

C N5 ISA SEQUENTIAL FILE FOR STORING MEMBER INFORMATION 047< 

C N6 IS A DISC FILE IN WHICH MATRIX IS STORED 0475 

C NM IS THE NUMBER OF MEMBERS 0476 

C IT IS FILE TO WHICH PROGRAM WILL RETURN 0477 

C IS WILL CAUSE DIAGNOSTICS TO BE PRINTED 0478 

C NP IS PAGE NO 0479 

C NC IS NO OF COLUMNS IN '3 1 G MATRIX 0480 

C NX IS NO OF COLUMNS IN COMPRESSED MATRIX 0481 

DEFINE FILE 1 2 ( 1 bOO , 2 30 , U , I 2 ) 0482 

DOUBLE PRECISION A(1CJ,4) 0483 

NM = MCTIMt(O) - NM 0484 

NM = ( NM + 30 > / 6U 0485 

WRITE (3,1033) NM , NX 0486 

1033 FORMAT ( 17, 25H MINUTES TO INVERT SIZE , 15 / ) 0487 

SUM = 0. 0488 

L4 = NX/ 100 + 1 0489 

DO 1 K = 1,NX 0490 

K4 = K*4 - 4 0491 

DO 5 L = 1,L4 0492 

C5 READ{ N6«K4 + L)( A(I,L), I = 1,NX) 0493 

! IF (N5) 15,15,14 0494 

15 WRITE (3,103) K, (At 1,1), I = 1,NX) 0495 

103 FORMA! (/I10/ { 2X , 1 P 10D 1 2 . 4 ) ) 0496 

14 CONTINUE 0497 

DO 1 I = 1,NX 0498 

E = 0. 0499 

DO 2 J = 1,NX 0500 

OIJ = NX*J - r*X + 1 + 1 0501 

IF (I-J) 4,6,2 0502 

6 OIJ = OIJ * 10. 0503 

GO TO 2 0504 

4 OIJ = NX*I - NX + J +1 0505 

2 E = E + A ( J , 1 ) * OIJ 0506 
IF(I-K) 1,3,1 0507 

3 E = E- 1 . 0508 
1 SUM = SUM + E * E 0509 

E = SGRT (SUM /NX /NX ) * 100. 0510 

WRITE (3,100) E 0511 

CALL L INK ( 10) 0512 

100 FORMAT ( 18H RMS ERROR, PC ^ , F8.3) 0513 

END 0514 

/* TEB 0515 

// EXEC ASSEMBLY 0516 

MCTIME START 0517 

^ USING *,15 0518 

%J GET I ME BINARY 0519 

LR 0,1 0520 



BR 14 0521 

ENO 0522 

TEB 0523 

INCLUDE OVERLAY OS^ 

EXEC LNKECT ll 



TABLE: 6 LISTING OF THE SHORTEST PROGRAM THAT I COULD WRITE TO 0528 

INVERT A MATRIX STORED ON DISC . 0529 

0530 

//ftfB BJPL$ 0531 

//l*fPTION CATAL 0532 

PHASE BJPL$14,S 0533 

// EXEC FORTRAN 0534 

C THIS IS SHORTEST PROGRAM THAT I COULD WRITE TO 0535 

C INVERT HATRIX STORED ON DISC 0536 

COMMON N3, N4, N5, N6 , J I M , NM , I T , I S , N J , NP , NC , N X 0537 

DEFINE FILE 12(1600, 200, U , 12 ) 0538 

DOUBLE PRECISION 1(100,3), 0(100,3), Z(1C0,3), F,G 0539 

L4 = ( NX-1 ) / 100 + 1 0540 

DU 1 L = 1,300 0541 

1 Z(L,1) = O.DO 0542 
DO 21 K = 1,NX 0543 
K4 = r;*4 -4 0544 
DU 2 M = l,L4 0545 

2 R E A D ( N 6 ' K4 + M) (D(L,M) , L = 1, 100) 0546 
F = l.CO / D(K, 1 ) 0547 
Z(K,1) = l.DO 0548 
DO 3 N = 1,L4 0549 

3 WRITE (N6» K4 + M ) ( Z(L,M) f L= 1,100) 0550 
Z(K, 1 ) = O.DO 0551 
DO 21 J = 1,NX 0552 
J4 = J*<* - 4 0553 
DU 4 M = 1,L4 0554 

4 READ (N6 1 J4 + M) (T(L,M), L = 1,100) 0555 

C> T(K,1) = T(K,1) * F 0556 

J G = T ( K, 1 ) 055 7 

00 22 I = 1,NX 0558 

IF (I-K) 23,22,23 0559 

23 T(I,1) = T { 1,1) - C ( 1,1) * G 0560 

22 CONTINUE 0561 

DU 5 M = 1,L4 0562 

5 WRITE( N6»J4 + M ) (T(L,M), L = 1,100) 0563 
21 CONTINUE 0564 

CALL LINK (05) 0565 

END 0566 

/* TEB 0567 

INCLUDE UVERLAY 0568 

// EXEC LNKLOT 0569 

/* TEB 0570 

0571 

TYPICAL DATA FOR RUNNING PROGRAM 0572 

0573 

// EXEC BJPL$1J 0574 

14 60 X 60 MATRIX INVERSION BY PARTITIONING 0575 

113 25 X 25 MATRIX INVERSION BY BY SEQUENTIAL FILE 0576 

113 60 X 60 MATRIX INVERSION BY BY SEQUENTIAL FILE 0577 

/* 0578 

/I 0579 
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COMPUTER REGISTRATION AT CHICO STATE COLLEGE 



Since the inception of computerized registration at 
Chico State College in 1965, the College has received 
numerous inquiries from other colleges as to how our 
system works and how it might be modified and implemented 
for other schools and other hardware configurations. Since 
no general computer-oriented overview of our system has 
been undertaken previously, this paper is an attempt to 
describe the salient features of what we at Chico State 
College believe to be the only successful large-scale 
genuinely computerized registration system. 

Like most California colleges, Chico State has recently 
experienced enormous growth. From an enrollment of 2,200 
full-time equivalent students in 1961, the College has grown 
to 6,738 FTE this fall. Such rapid growth (about 15% for 
several years) , with no abatement in sight for the near 
future, demanded that the College implement some form of 
automated registration. 

Perhaps the best overview of the impact of computer 
registration at Chico State can be gleaned from a description 
of the process as executed under essentially a manual system 
and a description of the corresponding automated systems. 

Prior to 1965, scheduling of students into the many 
sections of each course was effected by what we refer to as 
"arena" registration: on the Thursday, Friday, and Saturday 
preceding the first day of classes, the college's gymnasium 



2 



was equipped for mass student registration. For some time, 
record-keeping functions were assisted by unit-record data 
processing equipment. To register in the College, a 
student, having previously applied to and been admitted to 
the College or continuing from the previous semester in good 
standing, would be given a packet of punched cards which 
included a clearance card, study list, housing card, and 
the like. At the hour appointed for his class level and 
the initial letter of his last name, the student would 
proceed to the gymnasium. There he would wait, seemingly 
interminably, to be admitted to the arena. Inside, two 
major functions were performed — first, a student would 
select the classes he desired, proceed to the proper table, 
and, if the class he desired were not full, would be given 
an IBM card representing the class. If the student were 
exceptionally lucky, all his desired class sections would be 
open. If he were extremely unlucky, a class would close 
during the class-card gathering process and he would be forced 
to return his unwanted class cards, re-work his schedule with 
the help of an academic adviser, and start the class-card 
gathering process again. When he had all the desired class 
cards, he would proceed to the second phase: paying of fees. 
While the lines to pay fees were shorter and the time less 
than the waits to be admitted to the gymnasium and to 
receive class cards, the student was understandably grouchy 
after spending what was ordinarily about five hours in the 
registration process . 



It can readily be seen that the process of registration 
by the arena method for 6,700 FTE will require more time and 
facilities than for 2,200 FTE: something had to be done, for 
our time and facilities were simply running out. 

During the arena years, the class schedule was prepared 
entirely by hand, typed, photo-reduced, and printed. The 
secretary to the Vice-President for Academic Affairs would 
invariably spend the entire Christmas vacation period and 
the same amount of time during the summer manually preparing 
a list of all rooms and the classes to be taught therein 
during the upcoming semester. Inevitably, conflicts, empty 
rooms, and classes without rooms would appear which would 
frequently not be resolved until after classes began. As the 
College grew, physical plant utilization therefore dropped 
and confusion was the order of the day. 

Students would meet with an academic adviser in their 
major subject area and, together, the student and his adviser 
would prepare a program planning sheet for the student's use 
at arena registration. By 1965, this process could not be 
completed conveniently on the Monday, Tuesday, and Wednesday 
preceding registration allotted to the advising procedure. 

Moreover, all of the necessary but often irritating 
paraphenalia of student records, such as class lists, packet 
cards, grade lists, grade reports, and the like could not be 
conveniently prepared in the allotted time. 

Chico State's computerized system revolves around three 
distinct but interdependent systems: schedule preparation, 



student scheduling, and student record processing. 

One of the major effects of computerized registration 
has been the expanded time schedule for the entire process. 
Using the arena system, the major functions were performed 
from just before Christmas until mid-February for the spring 
semester, and from early August to late September for the 
fall semester. Computerized registration has so drastically 
altered the scheme of things that registration processes 
are underway at all times during the year. 

Chico State's registration process now begins with the 
computer center preparing, based on history and enrollment 
projections, a schedule request worksheet which is sent to 
the various academic department heads for their use in 
planning their course offerings for the upcoming semester. 
The schools and divisions of the College receive these 
worksheets shortly after the beginning of the preceding 
semester. Onto the worksheets the department heads write 
the requisite variable information, such as instructor 
number, class meeting times, building and room codes, and 
so forth. The completed worksheets are returned to the 
computer center for keypunching and verifying. The data are 
then submitted to the first in a series of major programs. 
This first program checks the schedule request against 
master lists of courses, rooms, instructors, valid times, 
etc., and produces listings of errors, omissions, and 
inconsistencies. The error listings are returned, together 
with a list of classes vying for the same room at the same 



hour, to the department heads for thier corrections. The 
entire class schedule is stored on a disk pack once, and, 
as corrections, additions, and deletions are made to the 
schedule, additional error checks are performed. During 
the first week of November for the upcoming spring 
semester and during the third week in April for the fall 
semester, a computer program prints a copy of the tenative 
class schedule containing class number, department name, 
department course number, course title, number of units of 
credit, instructor names, and times. Building and room 
are not printed in the tenative schedule. The schedule is 
then sent to a print shop for photo-reduction and insertion 
in every copy of the next issue of the Wildcat , the free 
student newspaper. 

The week following publication in the Wildcat is 
designated as "pre-registration" week. Each student 
meets with his adviser and prepares the successor to the 
program planning sheet. On the request form the student 
lists each class he desires, possbile alternates to it, 
the number of minimum and maximum units he will accept, 
states whether or not he will take any section of the 
course in order to get it, states any time restrictions 
he has, and similar information. The program planning 
sheets are then sent to the computer center for keypunching 
and verifying. 

From the student request cards, a tabulation of the 
number of students requesting each course is prepared and 



sent to academic department heads and college administrators* 
Based on demands for each course, departments may revise 
the schedule as required. During all phases of the schedule 
preparation, updated room lists, conflict lists, and lists 
of available space are frequently prepared, thus providing 
a great degree of flexibility and control over physical 
plant utilization. As an example, virtually no room 
conflicts now exist the day classes begin, whereas many of 
the classes had no room or met in a room occupied by another 
class before computer registration began. 

When it is determined that the schedule is final 
(usually about four weeks before the beginning of the 
semester) , computer registration is actually run. 

Most registration programs for relatively large-scale 
use are "computer-assisted." Emphasis is principally on 
relieving facility and personnel problems of scheduling 
rather than on giving the student more choice and greater 
convenience in class selection. In this respect, our 
registration program is, I believe, unique, for it permits 
the student great latitude in course selection, time 
limitations, in fact, all of the advantages of ideal class 
scheduling with few disadvantages. 

In the spring of 1965, two Chico State College students 
were commissioned to determine if a computer program could 
be written for the 1620 to enable registration by computer. 
The students determined that a program could be written by 
writing one! Written for, and still operating on (in slightly 



modified form) a 20K card/disk 1620, the Chico State College 
registration program, as we call it, should actually be 
called a "scheduling" program. The registration program 
takes into account both student requests and the state of 
the schedule at the moment a student is processed. The 
process of scheduling is markedly similar to arena 
registration, but the computer does all of the work 
frustrating to students: in accordance with the student's 
requests, the program tries as many as 15,000 possible 
schedules before determining that it cannot find a 
workable schedule within the student- and college-applied 
restrictions. Where the student may spend upwards of three 
hours to find any workable schedule in the arena, the 
computer registers between 200 and 2000 students per hour 
on the 1620, depending upon the state of the schedule and 
how unrestrictive the student's requests are. When the 
program finds a schedule for a student which satisfies all 
requirements, a record of each class in which he is 
scheduled is punched, the disk records identifying the 
classes are updated to reflect the new enrollment, and the 
next student is processed. Three major characteristics of 
this program set it apart from most others seeking to 
provide the same sort of service: (1) the program allows 
great latitude and flexibility in any student's schedule — 
a student may apply sectioning, time, units, and course 
restrictions to prevent the program from giving him an 
unacceptable schedule; (2) when the program, as happens 
very frequently, is called upon to select a section from 



those available, it attempts to schedule on the basis of 
class size, from least full to most full, thus balancing 
the size of the sections on a continuous basis. Only in 
the event that no section of a class will fit will the 
program attempt to delete the class and substitute an 
alternate if the student has listed one; and (3) the entire 
state of the schedule is held static during his processing, 
thus attempts at alternate schedules are unaffected by 
other students scheduling. The only condition causing a 
student to be unscheduled occurs when the program cannot 
satisfy the student's listed minimum units. 

Irrespective of whether or not a student is successfully 
scheduled by the program, any errors the student and his 
adviser commit are logged and the program attempts to take 
corrective action. Among the many niceties in the program 
is the ability to include courses which have interdependent 
parts. For example, a Biology class may be divided into 
two hours of lecture, two hours of laboratory, and one 
hour of discussion each week. The student must register in 
laboratory and discussion sections which have the same 
instructor as the lecture section. The program insures that 
conditions of multiple-dependency such as the example are 
properly scheduled. 

When all the students have been processed, the output 
cards are sorted alphabetically on student name and run 
through a program which prints, in class-schedule style, 
a list of the classes in which the student is scheduled on 



continuous- form IBM cards. The separated cards are inserted 
in the proper student's registration packet together with 
his other registration materials. For the spring semester, 
the packets are then made available at the College Library 
for a period of several days. For the fall semester, the 
packets are mailed directly to the students. 

Lists are prepared showing how many students were 
scheduled into each section, how many seats remain, and 
the percentage of students entering the process who were 
successfully registered. 

The student now has the option of either accepting 
his entire schedule or rejecting it and participating in 
arena registration. It has been proposed and will soon be 
adopted that each student prepay materials and service fees 
and be required to accept the computer-generated schedule. 
At present, those who could not be registered by computer 
are required to register at a conventional arena. An arena- 
like arrangement is provided for spring semester for students 
to pay fees. Clearance cards from this fee-paying arena or 
from students who, during the summer, return their fees by 
mail, are matched against output from the computer 
registration run, class cards for the students who accepted 
their computer schedules are punched, and the remaining 
class cards for each course are punched, interpreted, and 
arranged for arena registration. 

Arena registration was held for one day only this fall, 
1967, for the first time in many years. Due to computer 



assistance in room utilization, class card preparation, and 
class status reports, more than 4,000 students were 
processed in the arena from 8 AM to 8 PM this fall. Of 
those, nearly 2,500 were entering freshmen and transfer 
students who cannot currently participate in computer 
registration. 

At the end of arena registration, class cards from 
both computer and arena registration are merged and class 
rolls are prepared. Updated rolls reflecting added and 
dropped students are prepared at regular intervals during 
the academic semesters. Chico State also has, in the form 
of the student record-keeping system mentioned previously, 
the usual computerized grade cards, grade rolls, permanent 
record labels, lists of the standing of each student, and 
many additional reports and services. 

Due to the size limitations of the 16 20 and the 
probability of a new, larger computer on the campus during 
the next few years, we have set several design maximums on 
all the systems. We have provided for a maximum of 100 
sections of any one course; 2,400 different course types; 
3,000 sections of classes; 750 instructors; 240 classrooms; 
9,000 students entering computer registration; and 47,000 
class cards. While the design maximums can be very much 
larger within the capability of our 1620, we do not feel 
that the allocation of the additional space on the system 
disk pack is desirable. For example, we presently sort, 
store, modify, and otherwise process virtually all of the 



data within the system on one disk pack which also stores 
all of the programs to use that data. To expand the size 
maximums of the system would require us to revert to card 
resident programs and/or additional disk packs. 

A new, more capable computer system, such as a 
System/360, will permit us to add additional flexibility 
to a request set for any given student. In addition to the 
obvious advantages of increased speed for all processing, 
a larger system would eliminate over 500 hours of sorting 
class and packet cards each semester. We would be able to 
generate an optimized class schedule based on history, 
enrollment projections, physical plant utilization, 
personnel idiosyncrasies, unique course requirements, and 
student desires, thus relieving the administration and 
department heads from much of the routine work now necessary 
for schedule preparation. 

Among the many features we will implement with a newer 
system will be student request by course only, with programs 
to select and schedule the corresponding laboratory and 
activity courses required. 

We have so often been asked about modifications and 
implementation for other machines and schools that I feel 
a few remarks might be useful. 

The system we have designed is restricted to a college 
employing a semester-to-semester schedule and student planning 
basis. Modification for the 1620 for a college or other 
school desiring to plan college and student schedules more 
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than one semester in advance seems unlikely, for we have 
stretched the capability of the 1620 nearly to its breaking 
point. I am certain that long-range scheduling is possible 
and desirable for any school having, say, a large-scale 
1401 or a 360 system having a disk. I have carefully 
examined other IBM and some non-IBM systems for simplicity 
of adaptation and implementation of our system and I can say 
certainly that the system as we use it could very easily 
be processed on a single-disk 12K 360 model 20. It should 
be obvious that a system with capabilities as great as 
the model 30 lends itself well to expansion of our system. 

While the restrictions on size we have imposed upon 
ourselves may seem important, it is highly unlikely that 
any college much larger than Chico State would want to 
implement the system if the largest machine available to 
the school were a 1620. We have been asked if the system 
can be implemented on an 1130 disk system. It can indeed 
be implemented successfully, albeit on a smaller scale, 
due to the size limitations of the 1130 disk. 

Chico State's system is based on a six-day week, 360 
15-minute periods-per-week system of time. This arrange- 
ment is not fundamental to the system, however, and could 
be changed without difficulty: while our system is designed 
for a six-day week, Chico State is, at present, largely 
a f ive-day-a-week school. 

By far the most frequent question we are asked is if 
any part of our system is dependent upon the characteristics 
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of the 1620. Let me assure you that, even at the time the 
system was designed, we considered the 162 at best an 
interim machine and, as such, we have always insisted to 
all who have worked on the project that it remain free of 
machine dependencies. While re-programming would, of course, 
be necessary for implementation on other hardware, conversion 
or modification for a new computer will not be at all 
difficult. 

Significant in the development of the entire system 
are two facts: (1) many ideas were conceived and all 
programs were written entirely by students at the College; 
and (2) when the idea for the registration program was born, 
IBM Systems Engineers were asked if it could be done on 
our 1620. Their reply: not even on a 60K, four-disk 1620 
model II. Chico State College is indeed fortunate to have 
students rebellious enough to doubt all that they are told 
is and is not possible. 
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STUDENT INFORMATION SYSTEM AT CHRISTIAN BROTHERS 
COLLEGE USING AN IBM 1130 COMPUTER 

In 1963, a system of records and grade reports adapted to the 1620 
was initiated. This was a minimum configuration consisting of a 40K 
memory, a 407 for print -out, an 082 sorter, and several key punches used 
also for interpreting and reproducing. This was basically a unit record 
operation with the computer used for calculations. There was a great 
deal of hand work involved in every operation . 

This summer, an 1130 with disk, 8K word memory and an 1132 
printer was installed. The immediate problem, then, was to reprogram 
the system making it adaptable to the 1130. This new machine had many 
advantages with its on-line printer and its disk storage for direct access 
to student information. It should be noted that IBM has prepared a 
Student Information System for the 1130 available from the COMMON 
library (3.0.003). For several reasons, it was decided not to use this. 
One important, reason was that there was no provision made for storing the 
student's address. Since there is a great deal of correspondence between 
school and student, it was essential that this be included. There were a 
number of other variables in the old system that had not been included in 
the IBM Student Information System. Because of the shortness of time, it 
was desirable to keep as many of the features of the former method as 
possible. Another important reason for not adopting it was the fact that it 




had been written in Assembly language. While it is probable that it could 
have been adapted, it was felt that there would be many problems and 
difficulties involved in trying to revise a large assembly program. There- 
fore, it was decided to start from scratch and to write a system in Fortran 
incorporating all the data forms of the previous system. This probably 
runs a bit slower, but the ease in reading, debugging, and revising seems 
to make it well worth the time. 

The first problem was to lay out the student file. It had been more 
or less arbitrarily decided to attempt to store two students per sector. 
However, most attempts at planning it ended with more than 160 words 
required. This difficulty was solved by adapting several of the subroutines 
from the Commercial Subrouting Package (1 130-SE-25X) . These are 
similar to the Forcom routine for the 1620. One basic advantage that these 
new ones have is that, with two or three exceptions, they are written in 
FORTRAN so that they can be modified with a minimum of effort. They are 
called in the same manner as are FORTRAN subroutines. Of primary 
interest is the Pack/Unpack subroutine. This takes an array in Al format 
(one character per word) and converts it to A2 format (two characters per 
word), thus halving the amount of storage required. A GET subroutine 
converts from the A-format to decimal form for arithmetic operations , and 
a PUT subroutine accomplishes the reverse conversion. 

The student file finally decided upon was set to contain 320 characters. 
When operating on the file, these characters would be in Al format, and 



then packed to 160 A2 format characters for the purpose of storage. Thus 
two students occupy one sector on the disk. As can be seen in Figure 1, 
this was more than ample for our needs, and it had space for additional 
information that might need to be added as time went on. 

The system works in the following manner. As was mentioned above, 
as much as possible of the old system was kept intact. From the applica- 
tion blank, the student's name is punched and he is assigned a student 
number. The student number is a five-digit number assigned in alphabetical 
order. In originally setting up the student file, they were read into the 
computer without regard to order. The computer then sorted them and so 
assigned a file number to each student. At the same time, it stores the 
student numbers in a separate file in the same order. Whenever a 
particular file is needed, the student number is read in. The computer 
then does a binary search using function subroutine RSEEK to locate that 
particular student's file. His file is read into core, unpacked, and the 
necessary information postioned, usually by means of an EQUIVALENCE 
or a PUT statement. The file is then packed and written back onto the 
disk. 

At the time of registration, the students pick up their own class cards 
after their schedule has been approved by their adviser. Positioning these 
behind the student's name card, they are ready to be read directly into the 
computer. The computer reads in the class cards for each student, alpha- 
betizes them, and stores them in the student's file in the manner described. 



This has eliminated the long process of gang-punching all of the class 
cards, and then sorting them into order first by course, and then by- 
student. The next program reads all of the classes from all of the files, 
and sorts the students into order according to their classes. Class 
lists are then ready to be printed and after that, the student information 
sheets. The latter are distributed in toto t o the Dean, Guidance Office 
and other administrative offices, to the dormitory prefects according to 
residence hall, and to the department heads according to the students' 
majors . 

Adds and drops are handled very easily. The very tedious job of 
pulling drops and inserting adds by hand has been eliminated. It is now 
necessary to simply place the add cards after the student's name card, 
followed by the drop cards (coded with a 1 in column sever) and read 
them into the computer which then rearranges the student's file. The 
running of report cards has also been simplified. It is no longer necessary 
to gang punch the marks into each of the grade cards. The cards are 
simply sorted by grade and then read into the computer, switch settings 
indicating the type of mark that should be stored. Honor rolls, failure 
lists and grade statistics- are produced very easily, also. Permanent 
record labels are printed at the semester. 

New students can be added very easily once a student number has 
been assigned. The program finds the proper position and moves down one 



notch all those files that will be behind him, much as a Disk Utility 
Program does. Likewise, a student's file can be deleted with those follow- 
ing moved up one. Bills for each student are run off for the Business 
Office. The Student Directory, Teachers* Schedule and various types of 
statistics have been programmed also. Since the memory is quite small, 
each of these different operations requires a separate program, and in 
some cases, two or three linked together. This is, however, no great 
difficulty, since once they are compiled and stored on the disk, a 
simple XEQ command calls them into action. 

Improvements will be made when the two additional disks that are 
on order arrive. At that time, there will be more than enough storage to 
keep the student's entire four year course of studies accessible by the 
computer. The 1132 printer is quite slow, but the operations will be greatly 
speeded up when it is replaced by the 1403 printer. 

As presently set up, the system will handle 1200 students, 100 
instructors and 300 courses. Figure 2 shows the layout of the cards 
used as input. While no claims are made about the completeness or 
efficiency of the programs, the system does work well. With proper 
modification, it could probably do the job at other small colleges as well. 
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DISK STUDENT RECORD FORMAT 



Word Description 

1-21 Student Name 

22-42 Parents' Name 

43-62 Address 

63-80 City and State 

81-85 Zip Code 

86-105 Local address 

106-113 Local telephone number 

114 Graduation code 

115-116 Hours being taken 

117-119 High School rank 

120-121 High school courses 

122-129 High school average 

130-135 Date of birth 

136-145 ACT scores 

146 Dormitory code 

147-148 First time status 

149 Probation code 

150-151 Number of courses being taken 

152 Special student code 

153-154 Religious preference code 

155 Billing address code 

156-158 High school code 

159-160 State code 

161 Year in school 

162 Boarding status 
163-164 Major code 
165-166 Action code 
167-175 Blank 

176-179 Cumulative quality point ratio 

180-182 Cumulative hours 

183-185 Cumulative credits 

186-188 Cumulative quality points 

189-248 Course numbers and grades 

In groups of five: 
1-3 course number 

4 grade in course 

5 former grade if repeating 
249-251 Rank in class 

252-254 Number in class 

255-258 Semester quality point ratio 

259-261 Semester hours 

262-264 Semester credits 

265-267 Semester quality points 



Figure 1-b 
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CARD INPUT FORMATS 
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Appendix A. Programs used to set up and maintain student file 

RDNAM Read in name cards to initialize students 

RDATA Read in students' data 

RDSKD Read in students' schedules, any order 

CTSEC Count setions and prepare class lists 

PRLST Print class lists 

INFO Print student information 

AD DCS Adds and Drops 

COREC To correct student information 

ADNAM To put a new student in the file 

BILLS To prepare bills 

BILSM Billing summary 

PRTOT To print totals in each section 

ENROL Enrollment statistics 

DRTRY Print student directory 



Appendix B. 



Programs used at report time. 



PCHGR To punch grade cards and print grade report forms 



CLGRS 



To clear grade area and set Orientation mark 



RDGRS 



To read in grades 



CKGRS 



Check to see if all grades are present 



CORGR 



To correct missing grades 



GRSUM To prepare grade totals 



GRSM2 To prepare grade totals (second half) 



PRGSM 



To print grade totals and statistics 



CTACN 



To separate and store actions 



PRDL 



To print Dean's list 



FALUR 



To prepare failure list 



CLSTD 



To determine class standing 



30? 



Appendix C . 



JJtility programs 



RDCRS 



Read in master course cards 



RDTCH 



Read in teachers' names 



CTTCH 



Prepare teachers' schedule 



PRTSK 



To print teachers' schedule 



RDABM 



Read in abbreviated majors 



RDACN 



Read in actions 



RDEPT 



To read in department names 



RDPAB To read in department abbreviations (4 letters) 



RDPAA 



To read in department abbreviations abbreviated 
(2 letters) 



RDFIL 



To read in entire student file from four 80A1 cards 



RDMKS 



To read in and store the 12 possible marks 



PCHCD To punch class cards 



PRCIRS 



Print list of all courses 



PRFIL 



Print out student files 



PCHFL To punch entire student file 



STPRB 



To set probation code to zero 
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Appendix D. 



Mark Conversion 



The twelve possible marks are stored in a file in a specified order. 
In the student file they are given a code letter as follows: 
Mark Number Mark Mark Code 
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C 


4 


D 


D 


5 


F 


E 


6 


S 


F 


7 


U 


G 


8 


I 


H 


9 


WP 


I 


10 


WF 


J 


11 


Ex 


K 


12 


Au 


L 



The mark number is read in. The following steps set up the mark 

code: 



1 



2 

3 

The reverse process is used to determine the mark number from the 
mark code when printing reports . 



IF(MKNUM - 10} 1,2,2 

MCODE + -16320 + 256*MKNUM 

GO TO 3 

MCODE = -14528 + 256*MKNUM 
CONTINUE 



Appendix E. 



SUBROUTINES 



GET(RLVAR , JFLD ,1,1, ADJST) To get a real variable from an array. 



IGET(INTVR, JFLD , I, J) 



To get an integer variable from an array, 



PUT(RLVAR, JFLD,I,J) 



To store a real variable in an array. 



IPUTflNTVR, JFLD, I, J) 



To store an integer variable in an array. 



RSEEK(RLVAR, RARAY , N) 



To locate position of a real variable 
in an ordered real array. 



ISEEK(INTVA, IARAY, N) 



To locate the position of an integer variable 
in an ordered integer array. 



SORT (RARAY , N , RMODE) 



To order a real array. 



IS ORT( IARAY , N , MODE) 



To order an integer array. 



PACK(LIST,I,J,LPKD,K) 



To convert Al format to A2 . 



UNPAC(LPKD,I, J, LIST, K) 



To convert A2 format to Al. 
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SIG/CPR's progress in research since 1962 and some thoughts on 
problems which still face us. This review was in the form of 
a dialogue between a computer center manager, David B. Mayer, 
and a management scientist, Professor Ashford W. Stalnaker. 



Mo^eA: Good morning ladies and gentlemen. 

I represent both IBM and the ACM Special Interest Group on Computer 
Personnel Research. Originally, this group was known as CPRG (Computer 
Personnel Research Group) ; founded back in 1962 as a result of some discussions 
at the RAND Corporation. I guess one might say that psychologist Robert 
Reinstedt was a little lonesome for the company of some other researchers. 
He had been investigating the problem of programmer selection and discovered 
that there was indeed very little research on this subject — except in the 
hands of a few colleagues in his general professional area, namely, Dallis 
Perry at the Systems Development Corporation, Professors Raymond Berger and 
James Rigney at USC, Jim Tupac at RAND, and Dr. Sherwood Peres who was at the 
Sandia Corporation. He called these people together and they laid out a 
charter for CPRG in September 1962 at the American Psychological Association 
meeting. The group decided upon the final design of a test battery to be 
administered across the country to as many installations and experienced 
programmers as they possibly could find. The test battery consisted of the 
Programmer's Aptitude Test, (better known as the PAT) by Hughes and McNamara 
of IBM; the Strong Vocational Interest Blank; and a special trial test named 
the Test of Sequential Instructions. There was some personal background 
material covering education experience, and so forth. The results of this 
test battery will be included in the body of my talk, but at this point it 
suffices to note that we completed it successfully, and we calculated 
correlations on the data, obtained much information, and initiated the kind 
of research that CPRG performs. 

The initial researchers went on from that point to develop a Programmer's 
Appraisal Instrument, which is an evaluation device. This was the result of 
Dr. Sid Fine's work with Robert Dickmann (now SIG/CPR Chairman) at Johns 
Hopkins University. It was tested there at the Applied Physics Laboratory, 
and at 24 other installations. 

The next step in our research was aimed at advancing the state-of-the-art 
of interest tests. The Strong Vocational Interest Blank had been revised 
(this had nothing to do with CPRG) and, after additional testing, Dallis Perry 
developed a key for programming as a separate occupation. 

In 1966 ACM approached us — they thought that we were doing so well 
that we should join the computing fraternity, since originally CPRG was composed 
primarily of psychologists with only a sprinkling of computer managers. We 
agreed that joining forces with ACM allowed CPRG's research to be enhanced 
through broader contacts and outlets. Hence, in this survey paper today, 
I would like to detail some of that research history, and some of the 
existing issues as we see them at this time. 

First, permit me to tell you a bit about the use of some of these tests 
in selecting computer personnel. 

Figure 1 summarizes the results of the Dickmann survey of 1966 which 
was reported at the Fourth Annual Conference (1) . This figure indicates 
that 483 firms in the United States and another 98 in Canada participated 
in the survey. In the US 68 percent used tests in some form or another 
for selection. This corresponds very closely to 72 percent in Canada. The 
number of programmer- analysts actually employed by these organizations was 



over 23 thousand in the United States, with another thousand in Canada. 
The number of people who are needed in the forthcoming year as of the time 
of this survey was another 25 percent. 

Figure 1 also shows the composition of the sample by industry groups. 

The kinds of programming being performed were basically of four major 
types - BUSINESS, SCIENTIFIC, SOFTWARE or MILITARY, or combinations of these 
(Figure 2) . Of them, the largest percentages were in business computations 
with scientific applications coming in somewhat lower. Military and software 
programming were small by comparison. 

What kind of programmers are there? We classified them at the 
time the survey was designed into four major categories: a programmer who 
was essentially a junior or trainee; the second one was called the experienced 
programmer; a third level we called the system analyst trainee; and the fourth 
one was termed the experienced systems analyst. Figure 3 answers the question 
as to what kind of education is demanded by the various institutions or 
organizations in their hiring practices. In the United States it tended 
toward having some college training or a degree - over 50 percent of the 
US sample, especially for the programmer-trainee. This tendency is 
a little more emphasized as you move up the experience ladder. Canada's 
educational requirements were somewhat lower, possibly because they do not 
have as large a college population from which to recruit. In Canada, 65 
percent of the programmer trainees had only a high school education and the 
remainder had some college or above. If you consider the experienced Canadian 
systems analysts, you will find that 28 percent had a high school education 
or better. However, 37 percent were not reported, so we can only generalize 
about the true proportions in this situation. Canada, therefore, is drawing 
on its resources of personnel in accordance with what they have available. 

Tests were used in many of these organizations, but they were used 
differently depending on whether the firm required much education, or little. 
Or to put it in reverse, possibly tests were NOT used in many cases, and 
hence the educational requirement was increased to compensate. Taking 
one category as an example, the systems analyst trainee, almost 50 percent 
were required to be college graduates if tests were not used; if a test were 
used, only 39 percent were required to have college degrees. This pattern 
repeats itself throughout Figure 4. We will not dwell on this except to 
note that tests are used in many cases in conjunction with educational 
requirements, but in differing degrees. 

What types of tests are used in these two countries? The tests 
reported used were broken down into four major classifications as shown in 
Figures 5 and 6. The first major classification is the general intelligence 
test with the most commonly used being the Wonderlic Personnel Test — 
60 organizations in the US and 7 in Canada. 13 of these organizations had 
undertaken validation studies of this test. Whether the validation studies 
consisted of actual on-the-job performance validation or training validation 
was not indicated in the survey. The other two principal tests used are 
general intelligence tests. 

The second type is the aptitude test, which is being used as if it 
isolates programming as a separate and special aptitude. The IBM Programmer 



Aptitude Test, PAT, is by far the most commonly used test in both countries: 
over 282 organizations in the United States — approximately 83 percent, and 
67 in Canada. Of the remaining aptitude tests, the National Cash Register 
Test, the Science Research Associates Test Battery and several others were 
used, but nowhere nearly as widely as the PAT. The Federal Service Entrance 
Examination is not a true aptitude test - it is a test, I believe, that is 
given to almost any prospective federal service employee, for many different 
positions. 

The two other types found in the survey were the personality tests 
and the interest tests. Very few of them are used. Personality tests were 
being used by only 10 or 15 organizations and very sparingly at that. For 
example, the Thurstone Temperament Schedule and the Activity Vector Analysis 
were each used by only three organizations ; several others were used in 
varying degrees . 

For the interest tests, the Kuder Preference Record was cited by only 
two organizations. Interestingly enough to me, neither Strong Vocational 
Interest Blank (SVIB, original or revised version) was mentioned by any 
organization. Yet it is one of the few for which there exists a key for 
programming. It is hoped that SIG/CPR will have some educational effect by 
bringing the value of SVIB to the attention of those responsible for personnel 
selection. 

Among the other tests is the 1401 Autocoder exam, which was developed by 
Computer Usage Corporation. This test is a form of the Logical Analysis 
Device developed by Langmuir at the Psychological Corporation of America. 
This latter test, known as the LAD, was not cited at all, however. 

Let us take a look at the use of the PAT for a moment. (See Figure 7). 282 
organizations use it in the United States. 128 of them use it in combination 
with some other test. 154 use it alone. As for position levels at which it 
is used, for the programmer trainee - 278 organizations gave the PAT; for 

the experienced programmer and this is always a delicate subject for a 

computer manager who is interviewing candidates there were 138 organiza- 
tions; for systems analyst trainees - 142; and for experienced systems 
analysts - only 87. Of these, 71 organizations had performed validation 
studies - that is, how the performance of the programmer compared to his 
score on the PAT. 22 organizations, or a little less than 10 percent, 
actually discontinued the use of the PAT for various reasons. 

This completes our summary of the Dickmann survey, and I think it would 
be well worth while to go into some of these tests and describe them and 
relate them to a sample test which you will take in a few minutes. 
Let us consider some of the several tests that have been used in various 
CPRG studies - — a sample of some of these were included in the small 
test battery which you just completed. In the original CPRG national survey (6) , 
three cognitive devices were included. These were the PAT, the Strong 
Vocational Interest Blank, and the Test of Sequential Instructions. The 
first of these, as was indicated by the Dickmann survey, is by far the 
most popular selection instrument in both the US and Canada. The results 
of the first CPRG study indicated positive correlations between 



the PAT score and actual performance only in a small number of cases. In 
the overall summary of the report, no correlation was found between the PAT 
and supervisory rankings of performance. The PAT has also been used in two 
studies subsequent to the CPRG national survey. The first was by Biamonte (11) 
at NYU working with a group of non-credit programming students, and the second 
by Gotterer and Stalnaker (12) at Georgia Tech with several groups of under- 
graduates enrolled in a computer course which had as a major component 
programming and systems analysis. In the latter case, as was true in the 
national survey, no correlation was found between PAT scores and performance 
in a training situation. We emphasize that the work at Georgia Tech was 
strictly in a training situation and in no way relates to subsequent performance 
in an actual programming assignment. 

Does such a thing as a programming aptitude really exist? Well, I have 
been trying to find that out from CPRG for several years. You know, after 
over a thousand interviews — which I'm told is the worst way to find out 
whether they are a programmer or have potential — and approximately 200 
people hired over my signature, I would say that I can detect what one might 
call an X factor; it's probably called aptitude. I do not know of what it 
consists; all I can say is that a particular candidate sitting before me 
seems to possess "it" and will succeed in the programming art. 

CPRG seriously questions that there is, as far as the training 
situation is concerned, any indication of a specific programming aptitude. 
Our interest was generated by the repeated occasions which were observed at 
Georgia Institute of Technology, wherein a truly marginal student — a 
student who was only barely able to maintain satisfactory status in school — 
was able to succeed in developing a rather sophisticated programming skill 
and also a sophisticated approach to systems analysis. 

Let us now look at some of the CPRG results with regard to the PAT (6) . 
As I mentioned, only in a limited number of cases was there a significant 
correlation between PAT results and ranked performance. However, I feel that 
one of the points that we should pay special attention to is the sort of cross- 
overs or the reversals we get in terms of the PAT. We will notice among the 
business programmers (Figure 13) who are graded in the upper half with regard 
to their performance, 42 percent of them scored 44 or below the PAT. On the 
other hand, among those who were rated in the lower half in regard to their 
performances, 49 percent of these scored 69 or above on the PAT. We might note 
too that the relationship in this case could be curvilinear. In the scientific 
group, Figure 14, the relationship is approximately linear and the degree 
of the reversals not as large as in the case of the business group. Here 
we note that 31 percent of those who are rated in the upper half with 
regard to the performance scored 44 or below, and 34 percent who scored in 
the lower half in terms of their performance scored 69 or above. 
In the sample there were 534 programmers; 301 of them were scientific 
programmers and the remainder were in business programming. There were 
25 different installations and companies. 

[kdmiviUtQJi and dU>cui>6 the, VTSl koAQ,) 

A second component of the national study (6) was the Test of Sequential 
Instructions. The author of the TSI states that it was designed to 




show that any test that in some way measures a form of logical reasoning 
will in some sense indicate the level of performance in programming jobs and 
will also indicate in some sense the intelligence of the individual* This 
hypothesis is borne out by the results of the national study in which the 
correlations between the TSI and the PAT were in many cases quite significant. 

In my scientific programming group I obtained a correlation coefficient 
of .70 between the PAT test results and my supervisor's rankings. But 
interestingly enough, on the TSI, the correlation coefficient was .71. So 
I naturally asked myself, what was I doing that was right? Could I inter- 
change the TSI with the PAT as part of selection procedure for programmers? 

The DTSI, to me, tests the ability to do multiple tasks simultaneously. 
To perform well on that test you are holding one task in the back of your 
mind while another task is being performed in the foreground. Then, we build 
up to 3, 4 and 5, in fact, in the real TSI, I think we have 7 tasks running 
simultaneously. The PAT, to me, has no such attribute. The PAT does test 

other components which are required in programming numerical capability, 

spatial relationships, and such. I suspect the two tests supplementary rather 
than interchangeable. 

The third component of the CPRG national the Strong Vocational Inventory 
Blank (SVIB) . The SVIB is a test that has been in use for a great number of 
years, primarily though, in the vocational counseling area. The purpose of 
the SVIB is to elicit information regarding the interests of the testee. 
The interests are then compared to the interests of people who have been 
successful in several occupational groups, the hypothesis being that if a 
person has interests similar to those successful in certain occupations, 
there may be some motivation to enter this occupational area. It should 
be noted that the SVIB is not claimed by its author to predict performance 
on the job; instead, it only elicits information regarding interests. 

In Figure 15 we compare the interests of computer personnel to the 
public in general in regard to certain answers to questions on the SVIB. 
The SVIB contains 400 items. Notice specifically the item on progressive 
people: 41 percent of computer personnel like this type of person — among 
the general public 85 percent of these people like people with this outlook. 
On the other hand, there is a great flocking among computer personnel to 
conservative people. 84 percent prefer these, while among men in general, 
only 56 percent. Another example was thrifty people: 45 percent of computer 
personnel stated they liked this attribute. They are much better liked 
by people in general — 74 percent. 

Can we look at individual items in the SVIB to see if these indicate 
anything in regard to the general interest pattern that should be the pattern 
of a successful programmer. The answer to this is a decided NO. We mentioned 
two categories — progressive and conservative people. The results shown by 
the SVIB are reversed in work by Biamonte (7) at NYU in which he specifically 
considered attitudes. He shows there were negative correlations between 
training success and such attributes as dogmatism, conservatism and 
authoritarianism, a finding which would indicate the reverse of your 
conjecture. The point is that the SVIB questions when taken out of context 
have no meaning. One must analyze the complete 400 questions in order to 
elicit anything regarding the total interest pattern of the individual. 



The normal scoring of the SVIB is quite complex because it has 
to be scored for all occupations. It is possible, I might mention, to 
hand-score for a particular occupational group. For instance, since 
the interest of this group is the computer programmer, it could be that 
the keys could be obtained and thus we could hand-score for this specific 
occupation. However, I would like to warn against this; the SVIB is 
meaningful only in terms of its total content. When we take an occupation 
or a question out of context, the results are questionable to say the 
least. 

I have mentioned the existence of the programmer scoring key for 
the revised SVIB. The series of questions that you have in your sample 
battery are from the old SVIB which was the one used in the original 
CPRG national study. Subsequently, Dallis Perry (8) undertook another 
national study in which he used the revised SVIB. He also worked with 
a larger sample than that included in the original CPRG study. Based 
upon this work, Perry has developed the programmer scoring key which 
is now available to all users of the SVIB. 

I think now we should move onto the topic of programmer evaluation — 
how can we determine if a programmer is actually effective on the job. 
The first research in this area was reported by CPRG. This was the Programmer 
appraisal Instrument (4) developed at the Applied Physics Laboratory, under 
the direction of Bob Dickmann and Sid Fine. This is a multi-dimensional instrument, 
which in many ways appears to be more concerned with what might be regarded 
as a professional programmer rather than the operating programmer - at least 
I think this is sort of a summary of remarks made in the evaluation of the 
PAI. There is a considerable emphasis on professional activities and this, 
in some cases, has led to resistance. It is composed of four specific areas: 
professional preparation and activity, programming competence, dealing with 
people and adapting to the job. This instrument was validated by Bob Dickmann 
but is not believed to be widely used at this time. 

The PAI asks a number of items to be scored numerically, such as: how 
many societies does he belong to? and how old is he? does he give some on-the- 
job training — a lot, or not at all? A supervisor finds that the items do not 
really cover the subject of programming , or programming capability . Super- 
visors generally shy away from ques tion-and-answer procedures for appraisal 
of programmers. Practically none have actually put this PAI or equivalent 
ratings into effect. Progressive as I am - I haven't either. My project 
leaders were very resistant to it. They prefer to use subjective techniques, 
such as their impression of the programmer's output; sometimes they actually 
read his programs. But a formal document of this type they resist. In 
evaluating a coder for upgrading to programmer, a better procedure would be 
to temporarily take a coder out of his current category and put him into 
direct programming tasks and to observe his programming capability rather 
than evaluating him through a questionnaire. Additionally, I would like to 
have some kind of test which will actually show his level of competence. 
A test that is concerned with programming ability to indicate readiness for 
the move from coder or programmer to senior programmer should be implemented. 
There is one further thing that must be done, and that is, as Dr. Paul Herwitz 
(13) of IBM has recently stated, the only way a supervisor can tell what a 




programmer is doing is by being knowledgeable about the code that he has written. 
In other words, he must read the program, and very few supervisors do. That 
would be the first step I would say towards proper evaluation. 

The second step would be to give a proficiency test, an objective one. 
In terms of such an objective test, Berger (10) at USC has developed a test 
which is called The Basic Programming Knowledge Test (BPKT) . This test was 
developed and validated with a group of naval training programmers and also 
with some outside agencies such as RAND, SDC, etc. Specifically, the test 
is designed to evaluate six different abilities: first, logic estimation and 
analysis; second, flow diagramming; third, programming constraints; fourth, 
coding operations; fifth, program testing and checking; and sixth, documenta- 
tion. Not only does the test evaluate the person's performance in these 
areas, but it is also designed to elicit information regarding his basic 
knowledge of the areas. Similar tests for different types of programmers at 
different levels would be very effective evaluators. The problem, of course, 
is the resistance the programmers show particularly as it applies to experienced 
ones who are very much in demand. 

We have cited the PAT, we have cited the Strong Vocational Interest Blank, 
we have cited the TSI. 

Now then, the PAT is an aptitude test, presumably, and the SVIB is an 
interests test; the TSI presumably tests a kind of logical capability . If I 
use all these tests and get good scores on all of them, does it mean I 
selected a good programmer? The answer at the moment is - no. I don't think 
it means that I have selected a good programmer - but it may well increase the 
probability that I have selected one. We have not been able to show at this 
point, with the exception of the recurring interest pattern of programmer 
personnel, any strong indication of substantially increasing the probability 
of correctly selecting a programmer by the use of this battery. 

Very probably if you would use all of the tests to select an individual, 
you can obtain a person who has a high probability of successfully completing 
y° ur training program. Whether this individual is going to like programming 
or will possess the motivation that will allow him to take the successful 
training onto the job site is a question that is not yet answered. 

Well, then I think we come to a small denouement, and it is that if we 
look at the past five years of computer personnel research, the major effort 
has been in the development of two sets of testing predictors: (Figure 16) 
testing for training success, and testing for job performance . We have said 
that we have good predictors for the training phase and questionable ones 
for the working phase. Temperament and motivation tests are frequently considered 
as good predictors of training success and job performance, but we have no 
research using them. Finally, of the "work sample" tests, the only proficiency 
test I know of is Berger 's Basic Programmer Knowledge Test. I understand 
that he will publish a version of it in the public domain, by permission of 
the Navy. For evaluation procedure, at the moment this consists of the Programmer 
Appraisal Instrument (PAI) which we developed but have not used. This I think 
sums up the situation at the moment. A more concise summary of our current 
knowledge is that the more intelligent person you can find, the better programmer 
you can probably get... which makes all of us here today good programmers! 



We might mention this point, that a test does exist that claims 
to be in this general area. This is the DPMA Certification program. 
However, I think we should note that it is quite questionable that there 
exists a relationship between this test and what we might identify as any 
level of programming skill. The DPMA test is primarily a knowledge test, but 
not at a very sophisticated level. It is my understanding that it is general 
knowledge — at least that is my impression from the groups that were formed 
to study for it. 

To summarize: We have called for several new procedures which should 
be investigated in the years to come. Despite the fact that I have been told 
time and time again by my psychologist friends that my or other people's 
interviewing technique cannot be a really effective device, it is still the 
one that I , as a computer manager, use in at least 50 percent of my evaluation 
of the candidate. Hopefully, if these new procedures can be developed, both 
I and my fellow managers will be better able to select, train, evaluate, and 
reward our computer personnel. Thank you everyone for your kind attention 
today. 
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United States 



Canada 



Organizations Participating 483 98 

Programmer/Analysts Involved 23,636 1,083 

Approximate Number Hired Each Year 5,317 (25%) 177 (20%) 



AIRCRAFT INDUSTRY (Industrial, 
Aerospace) 

ELECTRONIC INDUSTRY (Industrial, 
Electrical-Electronic) 

OTHER INDUSTRY (Petroleum, Metal, 
Automotive, etc.) 

FINANCE (Banks, Insurance Companies, 
etc. ) 

RESEARCH (Non-profits, University 
Labs, etc.) 

GOVERNMENT (Federal, State, and 
City Civil Service) 

UTILITY AND OTHER NON-MANUFACTURING 
CONCERNS 



United States Canada 



Number Percent Number Percent 

47 10 3 3 

35 7 2 2 

120 25 34 35 

81 17 21 22 

90 19 10 10 

50 10 8 8 

60 12 20 _20 

483 100 98 100 
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FIGURE 1: TYPE Of ORGANIZATIONS IN 1966 CPRG SURVEY 
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Bus iness 

Business and Scientific 

Business and Scientific and Software 

Scientific 

Scientific and Software 
Business and Software 

Business and Scientific and Software and Military 

Software 

Military 

Scientific and Software and Military 

Business and Military 

Business and Software and Military 

Other 



United States 
186 
84 
72 
44 
34 
33 
12 

6 

4 

3 

2 

1 

2 



Canada 
58 
11 
6 
6 
1 
1 






1 
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FIGURE 2: PROGRAMMING STAFF APPLICATIONS 
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Programmer 
Trainee 


Experienced 
Programmer 


System Analyst 
Trainee 


Experienced Systems 
Analyst 




U.S. 


Canada 


U.S. 


Canada 


U.S. 


Canada 


U.S. 


Canada 


None Specified 


9 


14 


9 


10 


7 


4 


8 


7 


High School 


27 


65 


19 


43 


13 


32 


11 


28 


Some College 


25 


3 


23 


6 


12 


16 


14 


10 


College Graduate 


34 


13 


35 


8 


43 


9 


40 


• 11 


Graduate Degree 


1 


2 


1 


2 


2 


7 


5 


7 


jnNot Reported 


4 


3 


13 


31 


23 


32 


22 


37 


100% 


100% 


100% 


100% 


100% 


100% 


100% 


100% 
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FIGURE 3: EVUCAT10NAL REOUUEMEhlTS 
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Programmer 
Trainee 


Experienced 
Programmer 


Systems Analyst 
Trainee 


Experienced Systems 
Analyst 


Non-Test 


Test 


Non-Test 


Test 


Non-Test 


Test 


Non-Test 


Test 


None Specified 


6 


10 


6 


10 


5 


8 


7 


8 


High School 


16 


32 


6 


25 


4 


17 


3 


15 


Some College 


27 


24 


19 


25 


10 


14 


7 


17 


College Graduate 


37 


32 


53 


27 


50 


39 


48 


36 


Graduate Degree 


3 


1 


4 





4 


1 


10 




Not Reported 


11 


1 


12 


13 


27 


21 


25 


21 




100% 


100% 


100% 


100% 


100% 


100% 


100% 


100% 
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FIGURE 4: COMPARISON/ OF EDUCATIONAL REQUIREMENTS FOR ORGANIZATIONS USWG 
TESTS IN SELECTION VERSUS ORGANIZATIONS NOT USING TESTS 
[UvuX&d States Sample.) 
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FREQUENCY OF USE* VALIDATION 
TEST NAME United States Canada Studies (Total) 

GENERAL INTELLIGENCE TESTS 



Wonderlic Personnel Test 


60 


7 


18 


Thurstone Test of Mental Alertness 


12 


1 


4 


Otis Tests (Unspecified) 


11 





5 


School and College Ability Tests (SCAT) 


5 





2 


Wesman Personnel Selection Test 


3 








Ship Destination Test 


3 








Lowry Lucier Reasoning Test Combination 


3 





2 


Concept Mastery Test 


2 





1 


Henmon Nelson Tests of Mental Ability 


2 





2 


Schubert General Ability Battery 


2 









APTITUDE TESTS AND BATTERIES 

IBM Programmer Aptitude Test 282 67 83 
National Cash Register Programming 

Aptitude Test (E51) 9 4 6 

Federal Service Entrance Exam 13 3 
SRA Computer Programmer Aptitude Battery 

(Burroughs Corp.) 5 3 1 

Employee Aptitude Survey 7 3 

Differential Aptitude Tests 6 4 
Watson Glaser Critical Thinking 

Appraisal 5 1 3 

Short Employment Tests 5 1 

Test of Sequential Instructions 2 1 

Minnesota Clerical Test 2 1 

Guilford Zimmerman Aptitude Survey 2 1 

Bennett Mechanical Comprehension Test 2 2 



*For Tests Used Two or More Times 
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FIGURE 5: TESTS USEV TOR INTERl/IEO/IWG 
PROGRAMMER CANVWATES: I 



TEST NAME 



FREQUENCY OF USE* VALIDATION 
United States Canada Studies (Total) 



PERSONALITY TESTS 



Thurstone Temperament Schedule 3 

Activity Vector Analysis 3 

Rohrer-Hibler-Replogle Personality Test 2 

Humm-Wadsworth Temperament Scale 2 

Edwards Personal Preference Schedule 2 

Cleaner Self Description 2 

Adaptability Test 2 

Guilford Martin Inventory of Factors 1 

Guilford Martin Temperament Profile Chart 1 



INTEREST TESTS 

Kuder Preference Record 



OTHER TESTS 



Manhattan Symbol (MAZE) 
1401 Autocoder Exam 
GCT 
LOMA 

Personagraph 



*For Tests Used Two or More Times 
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FIGURE 6: TESTS USEV FOR INTERVIEWING 
PROGRAMMER CANVWATES: II 



UNITED STATES CANADA 



NUMBER OF ORGANIZATIONS USING: 282 67 

IN COMBINATION WITH OTHER TESTS: 128 18 

ALONE: 154 49 

PERCENT OF TOTAL SAMPLE: 58% 68% 

PERCENT OF THOSE USING TESTS: 85% 93% 

LEVELS OF TEST USE: 

PROGRAMMER TRAINEES: 278 67 

EXPERIENCED PROGRAMMERS: 138 27 

SYSTEMS ANALYST TRAINEES: 142 32 

EXPERIENCED SYSTEMS ANALYSTS: 87 14 

VALIDATION STUDIES: 71 12 

DISCONTINUATION: 22 
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FIGURE 7: 1966 CPRG SURVEY 
IBM PROGRAMMER ATTITUDE TEST 
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PAT Scores 



Supervisors' Rankings 



Percentage In Upper Half Percentage In Lower Half 
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FIGURE 18: A COMPARISON OF THE RESULTS ON SAMPLE QUESTIONS TAKEN 
FROM THE SI/IB, AS 1NV1CATEV BY THE AUVTENCE POLL AT 
COMMON, PEC. 72, 7967. HOST OF THE AUVTENCE {WHICH 
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VJSPLAVEV ONLY TOR INTEREST: NO CONCLUSIONS FROM THE 
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ABSTRACT 



The Public Service Company of Colorado, a Gas and Electric utility, 
has installed the 1800 Data Acquisition and Control System in its Gas Load 
Control Center. 

The Gas Load Control Center has the responsibility of regulating 
and maintaining system pressures, contracted gas purchases, and gas storage 
facilities in the Company's service area. The computer system is monitor- 
ing variables from the field, logging hourly flow and pressure data, and 
controlling system pressures. 

This paper will explain the necessity and benefits of a real time 
computer system in the dispatching of natural gas. 
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1.0 SERVICE AREA 

Public Service Company of Colorado and its subsidiaries, 
Western Slope Gas Company, Cheyenne Light, Fuel and Power Company, and 
Pueblo Gas and Fuel Company serve natural gas to approximately 400,000 
customers in Colorado and Southern Wyoming. Natural gas is distributed 
in the Company's service areas through extensive transmission and dis- 
tribution systems. 

A general system map is shown in Figure 1. This graphically 
illustrates the great distances and rough terrain that must be encounter- 
ed in order to serve our customers. An example of this is the Western 
Slope Gas Company, Southern Division, transmission line that is 449 miles 
in length and crosses the Continental Divide five times. 

1. 1 SUPPLY 

Gas utilized by Public Service Company and Western Slope Gas 
Company, Eastern Division, is purchased directly from Colorado Inter- 
state Gas Company. Gas for this area is transported by Colorado Inter- 
state from the Texas, Kansas, Colorado and Oklahoma gas fields and from 
San Juan gas fields in the Four Corners area by connection with another 
pipeline company. This represents an investment of over $202,000,000 
by Colorado Interstate to serve its customers. Public Service and Western 
Slope represent over two- thirds of Colorado Interstate' s business and 
have a direct relationship in establishing purchase contracts and rate 
structures in this area. 

Gas utilized by Western Slope Gas, Western Division, is pro-e- 
duced from gas fields in Western Colorado. 

The Western Slope Gas Company, Southern Division, produces 
the gas it needs from the San Juan gas field in Southern Colorado. 

1.2 PURCHASE CONTRACTS 

Gas purchased by Public Service Company, Cheyenne, Pueblo, and 
Western Slope from Colorado Interstate is purchased under a two-part 
rate, consisting of a Contract Demand charge and a Commodity charge. 
The Commodity charge is the unit price on the actual volume of gas 
delivered by Colorado Interstate and the Demand Charge is the charge for 
the maximum volume of gas Colorado Interstate is obligated to deliver on ^\ 
the peak day. 
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Public Service and Western Slope are required to pay the Demand 
Charge on 1007 o of the Contract Demand each day and the Commodity Charge 
for the gas actually purchased. Penalties are charged the Company in the 
event that the Contract Demand limit is exceeded. As example of a sub- 
stantial penalty, in 1963, Public Service and Western Slope paid in ex- 
cess of $785,000 for gas that was purchased over the contract limits. 

The justification of such a rate structure is based on the 
wide range of load conditions that occur in the Colorado area. On July 16, 
1967, the mean temperature was 65 degrees F. with a 24-hour gas load of 
107,000,000 cubic feet. January 7, 1967 produced a load of 565,000,000 
cubic feet with a mean temperature of 16 degrees F. The mean temperature 
in Denver on January 11, 1963, was -17 degrees F. 

It is apparent that pipeline capacity required to meet peak 
winter needs becomes idle during warm weather. 

The two-part rate structure is needed to protect the pipeline's 
large plant investment that was made to serve areas during the peak load, 
while the load factor is at a minimum due to conditions such as warm 
weather. 



1 . 3 STORAGE 



It would be an advantage to Public Service Company of Colorado 
and Western Slope Gas Company to offset the varying load conditions by 
increasing the purchases from Colorado Interstate during off peak periods 
and decreasing the purchases on the peak day. This can be accomplished 
to some extent by storing gas during warm weather and withdrawing the same 
gas from storage when needed in cold weather. 

Public Service Company has converted an abandoned coal mine near 
Denver, Colorado, to an underground natural gas storage reservoir. This 
project, called Leyden Storage, is capable of storing 2,500,000,000 cubic 
feet of gas of which 1,250,000,000 is considered usable for peak shaving 
at a cavern pressure of 250 psig„ Leyden is connected to both Public 
Service and Western Slope service areas by a network of intermediate 
pressure systems (50-150 psi). An agreement also was made with Colorado 
Interstate for storage gas from its storage facilities near Fort Morgan, 
Colorado, to serve the Denver area. Both of these storage facilities 
are used during the heating season to control the load curve of Public 
Service Company of Colorado and Western Slope Gas companies. 
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A typical 24-hour winter load curve is shown in figure 2. For 



this particular day, all industrial customers were curtailed and 107,046,000 
cubic feet of gas was withdrawn from Leyden storage to maintain the contract- 
ed limits. An average hour load is shown by the line at 15.6 MMCF. 

1.4 INDUSTRIAL CUSTOMERS 

Industrial customers in our service area are under contract to 
purchase interrup tible gas. Interruptible Gas is gas that is available 
in excess of the amount required to serve the firm customer while still 
under the Contract Demand, The interruptible gas is sold to the industrial 
customer at a rate that is less than the amount paid by the firm customer. 
This rate class justifies the installation of a standby fuel system, such 
as, propane or oil. 



greater than 1007 o of the contracted demand and above the amount that can 
be supplied from storage, the industrial customer is given notice that 
he must curtail the use of natural gas and switch to standby fuel. When 
the daily load decreases to less than 1007 o of contract, the industrial 
customer is notified that he may resume the use of natural gas. 



service area and every attempt is made to keep curtailment at a minimum 
to optimize purchases and sales. The industrial load is approximately 
207 o of the contract on a cold day. 

The load curve that is shown in Figure 2 is with all of the 
industrial customers curtailed,, 

1.5 PRESSURE SYSTEMS 

In general, there are three types of pressure systems — High, 
Intermediate, and Low. The high pressure system is used for the trans- 
mission of gas over long distances. The operating range is from 200 psig 
to 1,000 psig. This type of system is usually a function of the trans- 
mission or pipeline company, such as Western Slope Gas Company. The 
high pressure system terminates at a city's town border station. 

A town border station is the point where the distribution 
company purchases gas from the transmission company for its system. The 
Denver area has six major purchase stations e 

Intermediate pressure systems operate in the range of about 20 
to 150 psig. Their function is to carry the gas through the market area 
and supply all of the city's district regulator stations,, In the Denver 



When the predicted load in a service area is estimated to be 



There are over 450 industrial customers in the Company's 
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area, the intermediate pressure system connects most of the town border 
stations with Leyden Mine Storage. This enables peak shaving gas to be 
injected into the intermediate pressure system which will result in de- 
creasing the purchased gas at the city's town border. 

Low pressure systems can operate in the range of 2 psig upward 
to 60 psig. Their function is to distribute gas to the individual customer. 

All of the pressure systems, along with compressors, valves, and 
regulators, provide a link that is hundreds of miles long which connects a 
customer in Colorado with the gas fields in Texas, Kansas, Wyoming, Okla- 
homa and Colorado. 

1.6 WEATHER 

Colorado area weather is the largest factor in determining the 
gas load. Weather forecasting and gas load forecasting are necessary to 
predict gas and pressure requirements. During the winter, it is not un- 
usual for a morning to be 60 degrees F. with the sun shining and by after- 
noon of the same day have the temperature drop to 10 degrees F., with wind 
and snow. This is caused by a storm front and, unless the front is pre- 
dicted, requirements for pressure and volume would be greater than the 
system could produce. 

1.7 CONTROL CENTER 

Public Service Company of Colorado, Western Slope Gas Company, 
Cheyenne Light, Fuel and Power Company, and Pueblo Gas and Fuel Company 
operate a Gas Load Control Center located in Denver, Colorado. This 
center is manned 24 hours a day, 7 days a week, and has the following 
responsibilities: 

1 - To calculate and log all of the hourly flow totals from 
metering stations for all four companies. Pressures, differential pres- 
sures, and flowing gas temperatures are telemetered to the Load Control 
Center from 32 major metering points located throughout the combined 
service area. This information which totals 114 different inputs is 
used together with various factors to calculate the gas purchased each 
hour at each meter station. The formula for the calculation of gas through 
an orifice meter is shown in Figure 4. A drawing of an orifice meter is 
shown in Figure 5. 

2 - To monitor and control (via phone conversation) compression 
facilities of the Western Slope Gas Company. Pressures from points locat- 
ed on the transmission lines are telemetered to the Control Center. This 
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information totals 39 input points. The operator can take action by 
ordering pressure output from a major compressor station or by notifying 
personnel in the area that needs attention. 

3 - To monitor and control intermediate pressure systems in the 
Denver area. Pressures from points located on the intermediate pressure 
systems are telemetered to the Control Center. This information totals 
42 input points. Control circuits, which set or regulate the pressure 
system, are activated from the control room. This totals 38 output points, 

4 - To monitor and control low pressure systems in the Denver 
area. Pressures from the low pressure systems are telemetered to the 
control center, totaling 61 input points. Control circuitry from the 
control room to a regulator station enables the operator to adjust the 
regulator's output to satisfy the demand on that station. There are 54 
output points from the control room to various regulator stations. 

5 - To operate all of the above pressure systems in a manner 
that guarantees safety and service to the customer without interruption. 

6 - To control purchase rates from suppliers and storage 
facilities maintaining optimum system requirements without exceeding 1007o 
of the contract demand. 

This requires the operator to estimate gas loads, weather 
conditions, pressure requirements, gas storage needs, and industrial loads 
throughout the operating day, and make the necessary decisions based on 
these estimates. 

7 - To provide management with reliable operating statistics so 
that the f uture growth and operating guidelines can be determined. 

The operation of a control center of this size requires that the 
operator maintain constant surveillance of all variables in the control 
room, calculate the flow rate for all meter stations, and predict the 
weather and gas load for storage requirements and industrial curtailment. 
With these responsibilities constantly increasing due to the continuing 
growth of the Company's gas service areas and more complex storage and 
system guidelines, a method was needed to relieve the operator of the 
time-consuming routine jobs. The time saved could be devoted to weather 
and system analysis. 

The 1800 Data Acquisition and Computer Control system was 
installed in August 1967 in the Gas Load Control Center. The computer 
is assisting the operator by providing a constant monitor of all system 
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pressures along with flow calculation and pressure control. This system is 
also providing management with valuable statistical information and a high- 
er degree of accuracy. The computer is enabling the operator to optimize 
the systems control. The chance that the 1007. contract demand figure will 
be exceeded is much less and a higher load factor is being achieved. The 
computer's speed allows all the pressure inputs to be scanned at a con- 
tinuous rate and if an erroneous condition occurs, it will alarm the 
operator as to what values need his attention. Thus, a higher degree 
of safety is obtained in pressure control. The computer is able to 
regulate a station's pressure output at a more constant rate than the 
operator can, which provides a lower average pressure throughout the 
system with resultant benefit in reducing the volume of lost and un- 
accounted for gas. 

One of the most beneficial aspects of the computer system's 
ability to handle the routine duties of an operator is that the operator 
has more time to use his experience and knowledge for planning and super- 
vision of the overall system. 

The computer's data flow and configuration are explained start- 
ing at 2,0 
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2.0 COMPUTER CONFIGURATION 

The 1800 computer system consists of the following: 

1801 Process Controller - 4 micro-second-16K Core 
12 Levels of Interrupt 

2 - 2310 Disk Drives 

1442 Card Reader 

1443 Line Printer 

3 - 1826 Input Units 
2 - 1053 Typewriters 

1816 Typewriter - Keyboard 

Timer A - 1 ms 

Timer B - 8 ms 

Timer C - 8 ms 

10 PISW Words on Level 

10 PISW Words on Level 1 
IBM "Time Sharing Executive" Operating System 
The computer's General Data flow is shown in Figure 6. The 
explanation of the software and hardware used follows. 

2. 1 TELEMETER INPUT 

The American Standards Association defines the word "telemetering" 
as "the indicating, recording or integrating of a quantity at a distance by 
electrical translating means." There are many types of telemetering systems 
available, and Public Service Company uses an impulse duration type. This 
system includes transmitters in the field and receivers in the Control 
Center. 

The transmitter contains a measuring element, such as, a Bourdon 
tube. This element is attached through linkages to a cam follower. The cam 
follower rides on a linear cam that rotates 360 degrees every five seconds. 
The pressure in the element causes the cam follower to be positioned on 
the cam in relation to the pressure in the element. The cam follower is 
connected to a mercury switch and when the follower is on the cam, an 
electrical circuit is made. When the follower is off the cam, the circuit 
is broken. The transmitter generates an electrical impulse every five 
seconds. The length of the pulse is determined by the time that the cam 
follower is on the cam, which is determined by the amount of pressure 
that is applies to the measuring element. If the measuring element is 



a Bourdon tube that is connected to a gas pipeline, an increase in gas 
pressure will cause the Bourdon tube to expand. This expansion will move 
the cam follower to a higher position on the cam which, in turn, will 
generate a longer time on the cam or a longer electrical pulse. A trans- 
mitter is shown in Figure 7. This pulse is transmitted over telephone 
lines to the Control Center. The pulse is connected to an electrical 
receiver which positions a recording pen on a chart that is in relation 
to the pressure on the transmitter in the field. The length of a pulse 
will vary from one second (07 o pressure) up to four seconds ( 1007 o pressure) 
See Figure 8. 

The Control Center receives 250 different pulses from points 
located on the gas system every five seconds. The distance the pulses 
travel varies from one mile up to 500 miles. 

A method of inputting the values from the transmitter to the 
computer was needed. At first we planned on using the conventional digit- 
al input system. Various programming techniques could be used but all 
of them required the computer to scan the input data every 3 milliseconds 
(ms). The 3 ms scan was needed to maintain one tenth of one percent 
resolution on a 5 second input (out of the 5 second pulse, 3 seconds of 
the pulse are used for full scale, 0% thru 1007 o , 3 seconds = 3000 ms 
.001 of 3000 ms = 3 ms). Using a 4 micro second computer, it would take 
longer than 3 ms to scan the inputs. If the computer's speed was in- 
creased to 2 micro seconds, more than 507, of the computer's time would 
be spent reading these inputs. A more efficient method of input to the 
computer was needed. An input system using the power of the 1800 com- 
puter's interrupt structure was developed called "Time Duration Tele- 
meter Input". 

Time Duration telemeter input is intended for use with time 
duration signals that have the characteristics of a starting time, an 
elapsed time, and a stopping time. Input to the computer is achieved 
through Process Interrupt words. One hardware timer is used to keep 
account of the elapsed times. If Time Sharing Executive software is 
used, one modification to the Timer Section is needed. This modification 
enables one timer to run continuously without requesting service. 

A signal that is sent from a transmitter is shown in Figure 9, 
Part A. Here we have a starting time (A), an elapsed time (X) and a 
stopping time (B). If the computer is interrupted at point (A) an in- 
terrupt servicing program can record the time of the interrupt using 
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one of the hardware timers. This time is kept in an array for the input 
as Time On. The next sequence would be the loss of this signal, or Time 
Off. Again the computer is interrupted at point (B) and a program records 
the time of the interrupt. By subtracting the Time On from Time Off an 
elapsed time is obtained and placed in an array as elapsed time. The 
final sequence for this particular input would be the second Time On or 
point (C). Again the program records the Time On as before, but now a 
new value is available, the total time required to send this signal. 
In telemetering systems, such as the one used by Public Service, this 
value can be used as a correction factor. A transmitter sends one sign- 
al every 5 seconds or 5000 ms. In cold weather, the cam speed can slow 
down causing the total time required to send a value to increase. This 
would also cause the elapsed time to be longer, thus creating an error 
in the value sent. The total time required for the cam in the trans- 
mitter to make a complete revolution is 5000 ms. If the total time 
that was actually sent is recorded, a simple ratio can adjust the elaps- 
ed time to negate any error caused by the cam either teeing too slow or 
too fast. See Figure 9, Part B. 

The advantage of using this type of input system is that the 
computer is freed from scanning. Instead of scanning the inputs to deter- 
mine a status change, the input interrupts the computer only when the 
change has occurred. In the Public Service Company application 160 
values were input to the computer at an estimated overhead of only 107 o 
of the computer's time. This can be compared to 1007„ of the computer 
time using digital input hardware. 

All of the input variables are output on logs to technicians 
so that they can calibrate the transmitter to the computer. 

Ten P. I. S. W. words were wired to level zero of the computer, 
these are used for all Time On interrupts. Ten P. I. S. W. words were 
wired to level one of the computer; these are used for all Time Off 
interrupts. One signal line from a transmitter is fed into a type "C M 
relay creating an On and Off interrupt to the computer from the trans- 
mitter. 

2.2 DATA CHECKING 

Every 10, 15 or 30 seconds, dependent upon the desired operation 
set by the operator, a program will interrogate the data placed in the 
computer by the input program. This program will check each input point 
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for any of nine error conditions. If an error is found in the data, a 
report will be made to the operator. 
Error Conditions: 

1. Off Scale - Below 07<, or over 1007<> of scale. 

2. Back on Scale - Was Off Scale - now reading is valid. 

3. Rate of change is over limits - The present value compared 
to the last value is increasing or decreasing too rapidly. 

4. Out of Limits - Value is out of limit bounds that are 
pre-set. 

5. Back in Limits - Value is now in pre-set bounds. 

6. Cam Speed Out of Limits - Cam in transmitter is either 
too slow or too fast on each 360 degree revolution. 

7. Cam Speed back in Limits - Cam in transmitter is now 
operating satisfactorily. 

8. Circuit Out of Service - Input line is out. 

9. Circuit Back in Service - Input line is restored. 

An array of last good readings is maintained by this program 
and if an input is found off scale, its last good reading will not be 
changed. This gives the computer an estimating capability in the event 
that an input circuit is out of service. 

2. 3 DATA PROCESSING 

Two types of inputs are processed by the 1800 computer, pressure 
and meter stations. Pressures are values on the system that are used 
for Control. A file is maintained for each pressure input and includes 
the following: 

1. Instant High - highest value telemetered. 

2. Instant Low - lowest value telemetered. 

3. Hour Average - last hour's average reading. 

4. Day Average - 24 hour average reading. 

5. Scale Range - Range of input. 

6. Off Scale - Number of times reading was off scale for the 
day. 

Meter Station values include static pressure, differential 
pressure and flowing gas temperature. See Figure 5. A file is maintained 
for each meter station and includes the following: 
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1. Instant high flow - highest flow calculated. 

2. Instant low flow - lowest flow calculated. 

3. Hour flow - Hour flow calculated for station. 

4. Day flow - Flow calculated for the day. 

5. Year High - Largest hour flow for the year (Peak Hour) 

6. Projected Hour - If the flow rate for this station remains 
constant, projected rate will be the hour load. 

7. Projected Day - If the flow rate for this station remains 
constant, projected rate will be the day load. 

Constants needed for information and calculation, such as 
orifice meter plate size, are also included in each statistical file. 

2 4 OPERATOR INQUIRY AND ENTRY 

Data such as gravity and plate size, needed for flow calculation, 
is input to the computer through the 1816 Keyboard typewriter. A program 
called "Key Board Monitor" enables the operator to queue up a function 
program from the keyboard by typing in the name for that program. Once 
the program has started execution, instructions such as the type and format 
of the data are typed out to the operator. The operator follows the 
instructions and enters the data the computer is expecting. This minimizes 
data errors and leaves typewritten copy on what data was entered, by 
whom and when. A sample of the input of a plate change for a meter 
station is shown in Figure 10. 

The operator can call out any variable in the same manner, by 
typing in the program name for the function desired. 

This type of output has greatly simplified the training of the 

operators. 

2.5 GAS LOAD FORECASTING 

Each year statistics on the last 26 years of weather and gas 
loads are applied against a model. From this data, a linear equation is 
developed y = a - bx, where y = forcasted load; a = y intercept; b = slope 
or forecast load per degree (F) change in mean temperature, and x is 
the expected mean (F) temperature for the day* An equation is developed 
for each hour for the remaining hours of the day for all four companies 
along with industrial equations for the industrial loads. These equations 
are solved in the 1800 computer each hour and a report is typed out 
to the operator showing the forecasted load that is equal to the fore- 
cast for the remaining hours of the day plus the amount already purchased 
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for all four companies. 

The output will also list the storage requirements and industrial 
curtailment needed to maintain gas purchase contracts. At the end of the 
day, a full report is made to the operator comparing the actual loads to 
the forecasted loads. 

2.6 DATA LOGGING 

System logs are typed out each hour showing flow totals, pres- 
sure readings, load forecasts and load projections for all systems con- 
trolled by the center. The format of the logs shows all of the variables 
that the computer used in calculating the flow rates. The logs are held 
pending for one hour to allow the operator time to correct the log if he 
disagrees with any of the computer data. If a correction is made, an 
amended log is typed out showing the computer's figure and the operator's 
correction. The only logs in use by the control center are the computer's 
output. 

System logs in a schematic format are also output to the operator. 
These logs show the pressures and flow rates on the system during peak 
conditions, and are a valuable tool for system analysis. 

At the end of each day, logs are output showing a summary of 
the center's operations for that day. 

2.7 CONTROL 

The intent of the control programs is to enable the 1800 computer 
to control the gas regulator stations delivery pressures under normal 
operating conditions. No provisions were made in the programs to handle 
abnormal conditions such as electric outages, line breaks or equipment 
failures. 

The operators on duty should have control over the system pres- 
sures in the advent of any abnormalities, since their experience would 
be needed to make the correct decision as to what pressures need adjust- 
ment. 

Eight low pressure stations were put on computer control. Each 
station has a tail end pressure. This tail end pressure is located in 
the stations service area at the lowest pressure point. A minimum pres- 
sure limit is held at this tail end point (usually 3 Psig) by raising or 
lowering the station's output pressure. Each individual station has its 
own operating characteristics, due to the size of the area served and 



the type of load in that area. The eight low pressure stations were 
chosen to provide statistics for next year's planning. An expansion of 
the computer system is under study that would enable the computer to 
control all of the low pressure and intermediate pressure systems. 

Both the delivery and tail end pressures are input to the 
computer to give the programs the information needed to take control of 
the station. Using this information and a target set pressure at the 
tail end, five decisions bands are set up to determine what action is 
needed. See Figure 11. 

1. Target Pressure + .250 Psig = Band one. 

If the tail end pressure is above this band, the computer 
will issue a lower command that is one half of a second 
in length to the delivery station, providing the end 
pressure is below the delivery pressure. One-half 
second is equivalent to approximately .25 Psig at the 
s tation. 

2. Target Pressure -.250 Psig = Band two. 

If the tail end pressure is above this band and below 
band one, the computer will take no action. 

3. Target Pressure -.30 Psig = Band three. 

If the tail end pressure is above this band and below 
band two, the computer will issue a raise command that 
is one half of a second in length or approximately .25 
Psig at the station. 

4. Target Pressure -.80 Psig= Band four. 

If the tail end pressure is above this band and below 
band three, the computer will issue a raise command 
that is one and a half seconds in length or approx- 
imately .75 Psig at the station. 

5. Target Pressure -.80 Psig = Band five. 

If the tail end pressure is below band four, the 
computer will issue a raise command that is two and one 
half seconds in length. If the tail end pressure is 
in band five, this could indicate a program or equip- 
ment failure as the pressure should not be permitted to 
enter this area. In addition to the raise command, an 
error message will be printed on the 1816 typewriter. 
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3.0 PHYSICAL PLANNING 

Eight month's prior to the expected delivery of the 1800 com- 
puter system, engineering and programming efforts were initiated. Re- 
modeling of the present facilities along with designing and installing 
the input system were to be completed one month prior to shipment. The 
programming was done in four distinct phases with a test on each phase 
at the IBM Test Center at San Jose, California. At the Test Center, 
experienced IBM personnel assisted Public Service in testing of its 
system. On the fourth and last test, the complete system was tested 
as a unit. Upon the completion of the test , all of the operating 
programs were stored on the disk packs. When the Public Service 1800 
computer system was delivered in August of 1967, these same disk packs 
were put on the system and Public Service was on Line, 
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4.0 FUTURE PLANNING 

At the start of the 1800 computer project, Public Service 
initiated a two phase program. Phase one would be to input 160 variables 
from the field to the computer, log hourly calculations to the operators, 
provide operation logs for the next year's statistical work and test 
computer control of a regulator station. At the completion of this 
phase, the computer is doing much more for the control center than was 
first planned. Eight stations are being controlled in the field instead 
of one test station. Engineering logs are being output showing the 
gas system's operation during peak periods. Operator entry has ex- 
panded to give the operator access to all of the computer's data, using 
a method that does not require the operator to be a computer expert. 

With the successful completion of Phase one, planning is now 
under way to initiate phase two. Phase two would expand the computer's 
input capability from 160 inputs up to 256 inputs. This expansion 
would allow all of the center's values to be in the computer. Output 
would expand to enable the computer to control all of the low pressure 
stations along with the intermediate pressure stations. This would 
require 100 output points. Both core and disk storage need to be in- 
creased to allow room for additional programs. 



5.0 COMPUTER OUTPUT 

The following four pages are output logs from the computer. 

Page one is the hourly system log showing all of the variables 
and contracts for the four companies controlled by the Center. 

Page two and three are engineering logs that were logged during 
the systems peak period*, These logs show flow rates and instant pres- 
sures in a schematic format. 

Page four consists of system error reports to the operator, 
gas load forecast and gas load projection called out by the operator. 
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0.656 


238. 


44.0 


10.8 








54. 


123. 


SI XT 


0.656 


145. 


34.0 


20.4 








403. 


403. 


ARAP 


0.656 


102. 


51.0 


32.2 


0.0 


0.0 


17.2 


836. 


0. 


APIL 


0.656 


102. 


50.0 


0.0 








0. 




CHER 


0.656 


140. 


47.0 


0.4 


0.0 


0.0 




38. 


0. 


CPI L 


0.656 


45. 


42.0 


56.8 








130. 




ZUNI 


0.656 


66. 


56.0 


42.8 


0.0 


17.3 




712. 


0. 


ZPIL 


0.656 


21. 


57.0 


17.9 








27. 




LEYI 


0.683 


233. 


29.0 


0.0 


0.0 






0. 


. 


LEYO 


0.683 


233. 


36.0 


0.0 


0.0 






0. 


0. 



0. 




0. 


0. 


0. 


0. 


0. 


1665. 


1608. 


6791. 


53836. 


6791. 


53836. 


0. 






177. 


1489. 


177. 


1489. 


0. 


403. 




1272. 


8891. 


1272 . 


8891. 


0. 


0. 


0. 


836. 


6353. 


836. 


6353. 


0. 






0. 


22. 


0. 


22. 


0. 






836. 


6375. 


836. 


6375. 





0. 




38. 


7567. 


38. 


7567. 


0. 






130. 


718. 


130. 


718. 


0. 






168. 


8285. 


168. 


8285. 





0. 




712. 


5467. 


712. 


5467. 


0. 






27. 


216. 


27. 


216. 


0. 






739. 


5683. 


739. 


5683. 









0. 


7603. 


0. 


11633. 


-4030. 






0. 


0. 


0. 


0. 


0. 



CARR 0.688 486. 57.0 13.5 
PLAT 0.688 158. 46.0 0.0 

(ESTIMATED MEAN TEMPS. REMAINDER OF DAY) 
LOAD FORECAST *MMCF AT 14.65 PSIA* 



DENVER DIVISION 
DENVER G-l 
NORTHERN COLO 
WEST SLOPE P-l 
CHEYENNE 
PUEBLO 

LI PAN AIR TEMP 3! 
C )-MANUAL INPUT 



472. 400. 0. 
0. 0. 0. 

DEN/ NO COLO 41. 



872. 
0. 



14655, 

7, 



CHFY 34. PUEBLO 41. 

TOTAL LOAD EST 



872. 
0. 

CARR+ 



14655. 
7. 

CIG CIG 



0. 
0. 



EST 


EST 


LOG 


-EST 


+ OR - 




M 1 NUS 


CARR+ PLAT 


EST 


ACCUM 


FIRM 


IND 


ACCUM 


CURT 


(SY.X) 


TOTAL 


BEST DECISION 


PLAT ACCUM 


LOAD 


LOAD 


163.2 


45.4 


131.4 


0.0 


12.0 


352.1 






398.8 


189.8 






128.4 






349.0 


-20.1 








41.3 


17.5 


35.8 


0.0 


8.0 


102.8 




21.4 14.6 










50.5 






117.5 


-21.4 








22.5 


3.9 


8.6 


0.0 


-85.0 


-49.8 


-96.7 








18.2 


6.6 


13.9 


0.0 


-45.0 


-6.2 


-61.3 








CHEYENNE AIR 


TEMP 36.6 


PUEBLO 


AIR TEMP 


24.9 FT. 


COLLINS AIR 


TEMP 30.2 







TUESDAY NOVEMBER 7 1967 311 

8:00 MST 



OPERATIONS ENGINEERING REPORT 
TOTAL DENVER LOAD AT 14.65 PS I A RASP 



G-l 19354. 



PLANTS 1888. + LEYOUT 
PS-1 GRANTED 
LI PAN A I R TEMP = 36.6 DEG.F. 
TOTAL DENVER CURTA I LABLE LOAD 
TOTAL DENVER CURTAILMENT LOAD 
F-S = 0. E-S = 0. D-S = 



0. 



0. 24G-S = 



0. - LEY I N 0. CARR-PLATTE 802 . 

IS-2 GRANTED 0. 

COINCIDENCE =14.0% 
(41.0) DFG. MFAN TEMP. = O.MCF 
(41.0) DEG. MEAN TEMP. = 10182. MCF 
0. r-S = 0. TOTAL = 10182. MCF 



TOTAL 22044. MCF 



LEYDEN MINE 

-P 

I NJ. 
WITHD. 

F-358 
85. # 



O.MCF 
O.MCF 



P 88TH CARR 

•R 

R 802 . MCF 
515. # 
F-340A 
87. # 
F-340B 
89. # 



74.#NORTH 
P F-210 
R 58.#SOUTH 
P 
I 



I I 
I I 
♦ -- + 

I 
I 

+---P F-171 I 
-+ 80. # I 

F-402 P 
1578. MCF RP---+ 
39. MCF W-E I 
122. # W 126. #F + 



F-161 

-PR 

107. # 



CHEROKEE 

R*P 131. MCF 
I 142. # 
I 



88TH PLATTE 

PR*- 

O.MCF 
158. # 



F-392 

R*P 

NORTH TB RR 

143. # I CITY 
6479. MCF I 



F-80 
ARSENAL 

R*P 

179. MCF 
242. # 



97. # 



I I 



P F 
52 



I 

• + - + 



+ - 




1 


1 
1 






1 

1 F 


1 

-362, 1 






*RP 










O.MCF 1 








83. #W I 


L.P. 


STATIONS 


1 










STA. 


DEL. 


END 


JEWELL 


2 


4.8 


3.0 


1 


7 


46.4 


23.2 


1 


23 


0.0 


0.0 




76 


6.3 


3.1 


1 


F-4 


0.0 


0.0 


1 


F-7 


6.7 


4.5 


1 


F-191 


0.0 


0.0 


1 


F-230 


7.8 


2.8 


+ - 


F-269 


0.0 


0.0 





ZUNI 
721. MCF 
68. # 

STA 11 
68. # 



ARAPAHOE 
*P 1036. MCF 
I 103. # 



*P- 
I 
I 
I 

P 



F-3 P— 
96. # 



-+- + 
I 

+ + 

I 
I 



R*P 
F-308 
6TH AVE 
1083. MCF 
145. # 



87. # 



P F-407 
89. # 



F-12 
PR 

112. # 
************ 

* * 

* *=MTR STA* 

* R=REG. * 

* P=PRESS. * 

* #=PSIG. * 

* * 
************ 



+-P YALEJCT. 
•RRP F-248 

I 100.#EXP. 

I 134.#YALE 

R 

— P* HAMPDEN 
I 11613. MCF 
I 148.* 
I 
I 
I 
I 



I 

CHERRY CREEK R*P 
6. MCF 
0.# 



TUESDAY NOVEMBER 7 1967 311 
TIME 8:12: 6 



WESTERN SLOPE GAS EASTERN 01 VISION 



NORFOLK 
R*P 



I 
I 

P 

LA PORTE 
4 86.* 



253. 1CF 
648. # 



OPE^ATIOiiS ENGINEER 
LOADS AT 14.65 



♦ ♦♦LEGEND* ** 

♦ * 

♦ ♦=;:tr sta* 

♦ p- press * 

♦ U = REG . * 

♦ #«P3in. ♦ 

♦ ♦ 
************ 



liG REPORT 
PS I A. 



FT COLLINS 

+ P NO. 30*. # 

I 

PIP. 02. # 
I 

+- — P SO. 254.* 
AIR TMP. 20.5 



p +. 

BOULDER +■ 
31*5. # 



GREELEY 
R*P 

15'j7.MCF I 40 7. # 



PS-1 GRANTED 
IS-2 GRANTED 



+ + 



O.MCF 
O.MCF 



( + — -+ 83G.#(10 INCH) 

+ + I 

I I 

I + + 

+ + I 

I I 

I + + 

590. #(15 INCH) + + I 

I I 

CARR P 471.* PLATTE I ♦--+ 

*R K^P +--+ I 

R 1062. MCF O.MCF I ♦ — 

LEYOEN ♦— + 158. # + 

O.MCF IN 

O.MCF. OUT EST MEAN TEMP 41.0 

P-l 6135. C-P 1062. NO COL 5073. LEY IN 



P 321.* 
•P 4285. MCF 
P^R MESA 



RATE 
S-MC 
l-NC 
E-NC 
TOTAL 



CURTAI LABLE 
O.MCF 
O.MCF 
O.MCF 
O.MCF 



CURTAI LED 
O.MCF 
O.MCF 
O.MCF 
O.MCF 



CHEYENNE LIGHT FUEL POWER CO. 



FRONTIER 

R*P 

7 6. MCF 
40. # 



CHEY I. P. 
119. # 

+ P- — 



I 
I 
I 



R^P 
TERRY 
451. # 
24 5..1CF 



R * P 
5TATELINE 
9 60.HCF 
420. # 



P-l 12 5. MCF 
FRONTIER 7b. MCF 
PS-1 GRANTED O.MCF 
IS-2 GRANTED O.MCF 
RATE CURTAI LABLE CURTAI LEU 
E-S u.MCF O.MCF 

EST. MEAN TEMP 31.2 
AIR TEMP 35.7 



PR- 



PUEBLO GAS AND FUEL CO. 



DEVI NE 

R*p-. 

84 5.IICF I 
321.* I 
I 



— -RP 
BOONE 
117.* 





1 G-l 


2 244. MCF 


SCP580.MCF 


PS-1 GRANTED 


0.1 
1 






IS-2 GRANTED 


0.1 








1 RATE 


CURTAI LABLE 


CURTAILED 




1 F-S 


O.MCF 


O.MCF 




1 

1 E-S 


O.MCF 


O.MCF 


i 

SO COLO POWER 1 D-S 


O.MCF 


O.MCF 


R^P 


1 






580. MCF 1 33 


.# 1 c-s 


O.MCF 


O.MCF 




1 TOTAL 


O.MCF 


U.MCF 




R^P 


EST MEAN TEMP 41.0 


SO 


TOWN BORDER 


AIR TEMP 24.1 




139. # 








1401. MCF 







( ) MANUAL HOURLY ENTRY 

TUESDAY NOVEMBER 7 1967 311 
TIME 7:32:37 



TIME IS 7:1*3: 2 ALAMOSA HIGH PRESSURE 

TIME IS 7:U3: 7 CHEYENNE INTERMEDIATE PRESSURE 

TIME IS 7:U3:16 F -210 INTERMEDIATE PRESSURE NORTH 



OUT OF LIMITS 160.8 
OUT OF LIMITS 124.1 
NOW BACK IN LIMITS 69.7 



(ESTIMATED 


MEAN TEMPS. REMAINDER OF DAY) 


DEN/MO COLO 


41. CHEY 


34. PUEBLO 


41. 








LOAD FORECAST 


*MMCF AT 


14.65 PSIA* 








TOTAL LOAD 


EST 


CARR+ 


CIG 


CIG 




EST 


EST 


LOG 


-EST 


+ OR - 




Ml NUS 


CARR+ 


PLAT 


FST 


ACCUN 




FIRM 


1 ND 


ACCUM 


CURT 


(SY.X) 


TOTAL 


BEST DECISION 


PLAT 


ACCUM 


LOAD 


LOAD 


DENVER DIVISION 


176.3 


48. 2 


111.8 


0.0 


10. 


346.4 








507.7 


161 . It 


DENVER G-l 






109.7 






344.2 


-25.8 










NORTHERN COLO 


44.0 


18.6 


30.5 


0.0 


10.0 


103.2 




21.9 


13.7 






WEST SLOPE P-l 






44.3 






117.0 


-21.9 










CHEYENNE 


24.2 


4.1 


7.2 


0.0 


-12.0 


23.6 


-23.2 










PUEBLO 


19.7 


7.0 


11.7 


0.0 


-4.0 


34.4 


-20.6 










LI PAN AIR TEMP 


28.9 CHEYENNE AIR 


TEMP 31.2 


PUEBLO AIR TEMP 


13.3 FT. 


COLLINS AIR 


TEMP 23.6 









LOAD PROJECTION AT 7:44:42 MST 



DENVER G-l CARR PLATTE WSGE 



18997. 



1118. 



0. 



6141. 



425291. 34421. 



7. 147725. 



LEYDEN IN LEYDEN OUT 
HOUR PROJECTION 
0. 0. 
DAY PROJECTION 
7603. 0. 



CHEYENNE FRONTIER PUEBLO SCP 



1316. 



28149. 



75. 



1783 . 



2250. 



580. 



49802. 13942. 



TIME IS 7:46: 3 ALAMOSA HIGH PRESSURE 

TIME IS 7:46: 4 ANTON I TA HIGH PRESSURE 

TIME IS 7:46: 9 CHEYENNE INTERMEDIATE PRESSURE 

TIME IS 7:46:21 CHEYENNE STATIC PRESSURE 



OUT OF LIMITS 158.4 
OUT OF LIMITS 169.5 
NOW BACK IN LIMITS 108.6 
OUT OF LIMITS 420.0 



TIME 


IS 


7: 


46:32 


TIME 


IS 


7: 


46:34 


TIME 


IS 


7: 


46:41 


TIME 


IS 


7: 


46:41 


TIME 


IS 


7: 


46:44 



NORFOLK GAS TEMPERATURE 
TERRY ROAD STATIC PRESSURE 
NORFOLK GAS TEMPERATURE 
TERRY ROAD STATIC PRESSURE 
CHEYENNE NUMBER ONE DIFFERENTIAL 



RATE OF CHG IS OVER LIMITS 
OFF SCALE 
MOW ON SCALE 
NOW ON SCALE 
CIRCUIT OUT OF SERVICE 



THE CATALYTIC CONSTRUCTION C0 o 
1528 Walnut St Phila<> Pa 19102 



A Program for Making a Non~ Linear Regression 
Analysis with up to Three Independent Variables 



By ToEo Bridge 

This program will be very useful for curve fitting It will develop 
coefficients for calculating a dependent variable (or function) when up to three 
independent variables (arguments) are specified,, There are nine options available 
involving various combinations of polynomial „ logarithmic^ or reciprocal relation- 
ships between the variables It was designed for system 360 Model 30 - 32K with 
2 disk drives o 

This program will also be useful if you need to correlate a large mass of 
test or operating data 

Four numbers and a title are read by the machine on the first card (4I2 P 18A4) 
Nl, N2, N3, N4 P titles 

NI specifies the degree of the fit for the first argument s N2 for the second, 
and N3 for the thirds 



N Type of Fit 

Is not permitted o 

1 Calls for a constant or average value for the 

function not influenced by the argument 

2 Calls for a linear fit. The machine will find a straight 
line that gives a minimum root mean square error 

3 Calls for a parabolic fit The machine will find a 
quadratic equation to give a minimum RMS error „ 

4 The machine will find a cubic equation to 
give a minimum RMS error « 



Any positive whole number or combination of numbers may be entered for Nl s 
N2 P or N3 8 so long as their product does not exceed 100 o 

You must enter a total number of data cards greater than the product of Nl x 
N2 x N3 The more the better „ 

N4 may be any digit 1 through 9 It specifies the option that is desired — 
or whether you want to try for a smooth fit on a graph with linear or logrithmic 
scales, or a semilogrithmic graph p or even on a graph with a reciprocal scale. 

Let Y represent the function^ and let XI X2 a and X3 represent three arguments 
fitted to a degree specified by Nl fl N2„ and N3 respectively,, Then fl the following 
table will p for each option specified by N4 8 show the type of graph that is assumed 
by the program * 



fa 



Regression Analysis Program 



2. 



N4 



Polynomial 



Logrithmic 



Reciprocal 



1 
2 
3 
4 
5 
6 
7 
8 
9 



Y, X2 , X3 

Y,X3 

Y 

X1 P X2,X3 



Y,X1,X2,X3 
X1,X2,X3 
X2 P X3 
X3 



Y 

Y P X1 

Y P X1 P X2 

Y,X1,X2,X3 



XI 

X1,X2 

Xl,.X2 fl X3 



Y 



Enter any desired symbol in columns 76-80 of the title card. The correlation 
coefficients (the answers) will be punched out by the machine ready for insertion 
in a Fortran program deck e Each coefficient will be indent if ied by the symbol 
entered in columns 76-80 of the title card. It is then a simple matter to write 
a Fortran program to quickly calculate the function from any given set of the 
arguments. A subroutine (TB$PLY) should be put in your relocatable library for 
doing this. 

CALL TB$PLY(N1,N2,N3,N4 P X1 P X2 P X3 P Y P C) 

C in the above call statement must be replaced by whatever symbol you put 
in columns 76=80 of the title card. Y is the answer or function, and XI p X2 P 
X3 are arguments corresponding to the fit parameters Nl, N2 P and N3 respectively. 

Data follows immediately behind the title card. Each card (or row on the 
data sheet) will include four numbers in order Y P X1 P X2 P X3. (4F10.3 P I5) 

The problem is terminated if a digit is read in columns 41-45. If a zero 
(or blank) is entered for XI , X2 P or X3, the program will enter the preceeding 
value for that argument. Therefore p if you want to enter a real zero, enter 
some very small number close to it, as p for example — .0000001. Of course, if 
you are making a logrithmic fit, you must not enter a negative value for the 
variable. 

Explanation of the Program 

I think that my explanation of this program will be a lot simpler if I 
talk about a specific formula rather than about a generalized one. Consider 
the following formula; 

Y = Ca ♦ Cb Xa ♦ Cc Xa 2 ♦ Cd Xb ♦ Ce Xb a ♦ Cf Xb Xa 2 

In the above equation, we are making a 3 point fit with respect to Xa and a 
2 point fit with respect to Xb. That is; if we hold Xb constant, Y will plot as 
a parabola against Xa; and if we hold Xa constant, Y will plot as a straight line 
against Xb. We will read from a family of curves a value of Y for each of many 
different values of Xa and Xb. Our program is to find values for Ca, Cb, Cc p Cd, 
Ce, and Cf that will best fit the data that we give. Let Yg be the given value 
of Y for any point corresponding to Xa and Xb. Let E be the sum of the square of 
all of the errors for N given points. 



7 



Regression Analysis Program 



3. 



E = I (Y-Yg) 2 

Differentiate with respect to Ca. Since we are looking for a minimum value 
of E, this derivative may be made equal to zero. 

dE/dCa = 2j" (Y-Yg)dY/dCa =0. 

but dY/dCa - 1 , therefore ; £ Y = £ Yg 

J Ca + £ Cb Xa + £ Cc Xa 2 ♦ £ Cd Xb + £ Ce Xa Xb + £ Cf Xa 2 Xb = £ Yg 

Similarly if we differentiate with respect to Cb, we can write another 
equation: 



dE/dCb = 2£(Y-Yg) * dY/dCb = 



but dY/dCb = Xa , 


therefore : 




£ Y Xa - 


I Yg Xa 




£ Ca Xa + £ Cb X&2 + Z Cc 


Xa 3 ♦ J 


[ Cd 


Xb 


Xa * £ Ce Xb Xa 2 + J 


[ Cf Xb Xa 3 = £ Yg Xa 


In this way, we can 
unknowns are Ca, Cb, Cc, I 


write 6 
2d , Ce , 


equations. Lets put them 
and Cf 


in matrix form. The 


Note that £(1) « N 














N j> £ 


Xa 2 




1 


*Xb 


£ XbXa 


£ Xb Xa 2 =£ Y S 


I Xa I ^ 2 J 


Xa 3 




1 


[ xt Xa 


I xb Xa2 


J Xb Xa 3 =£ Xa Yg 


y xa 2 y xa 3 y 


Xa 4 




1 


" Xb Xa 2 


£ Xb Xa 3 


£ Xb Xa 4 =£ Xa 2 Yg 


J" Xb £ Xb Xa J 


Xb Xa 2 




\ 
I 


» Xb 2 


Z xb2)(a 


£ Xb 2 Xa 2 =£ Xb Yg 


£ Xb Xa £ Xb Xa 2 £ 


Xb Xa 3 




3 


r Xb 2 Xa 


Z xb2x&2 


£ Xb 2 Xa 3 =2 Xb Xa Yg 


J Xb Xa 2 £ Xb Xa 3 £ 


Xb Xa 4 




1 


I Xb 2 Xa 2 


J Xb 2 Xa 3 


£ Xb 2 Xa 4 =£Xb Xa 2 Yg 


As we read in the data (in 


an array called 


X) we will 


calculate each term in 



the first equation and put in an array called U. 

The data read on each card is stored in file 11 so that it can be re-read 
after completing the analysis. At that time, we will calculate a value Y and 
compare it with the given value to see if we have a fit. Any positive number 
in columns 41-44 of a data card will signal the end of data. 

Each column of the matrix is stored as a record in file 13. At the beginning, 
we have to zero the matrix. This is done in statement 44, 

Immediately after we read each card, we must increment every term in the 
matrix as follows: 



Regression Analysis Program 



4. 



Do 9 M=1,NP 
Read(13'M) (T(K),K-1,N) 
Do 10 L=1,N 
10 T(L)=T(L)+U(L)*U(M) 
9 WriteClS'M) (T(K) ,K*1,N) 

Now, all we have to do, is to solve for the coefficients Ca, Cb, Cc, etc. 
These answers are punched on cards in a Fortran format so that they can be put 
right into your Fortran source deck to initialize your array. A symbol name was 
picked up from columns 77-80 on the title card, You need only write a dimension 
statement to reserve space for the array. 

If you put the subroutine TB$PLY in your relocatable library, you are all 
set to use it in any fort ran program. 

Table 1 is a listing of the main program TB$RA and the subroutine 
TB$PLY that expands the polynomial to fit the curve. 

Table 2 is an example of a regression that was made for the curves of 
figure 1 , 

The end of program TB$RA ( starting with statement 41 ) shows how you 
would use the program. This statement rereads all of the data from file 11 
and then makes a comparison between the given and calculated values for Y . 
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TABLE 1 LISTING OF PROGRAM FOR REGRESSION ANALYSIS 

/ZfcJim IMRA — — - -Q&QX 

/%|bPTION CATAL 000? 
JPHASE TB$RA01 f S 0aQ3 

// EXEC FORTRAN 0004 

c _ ...... 0005 

C MULTIPLE REGRESSION PROGRAM BY TEB 1967 0006 

C _ 0.0Q7 

C S AMPLE TITLH CARD ASSUMING 4 TERMS IiM EQUATION FOR XI , 3 FOR 000* 

C X2 , AND 2 FOR XI . 0009 

C 001 n 

C 04030201 TEST PROBLEM 1-23-67 Y VS XI X2 X3 001! 

c 001? 

C THE 04 IS CALLED Nl, 03 IS CALLED N2, 02 IS CALLED N3 » AND. ..01 IS. .0.013. 

C N4 IS A VARIABLE GIVING ONE OF NINE OPTIONS. IF N4 IS 0014 

C 1 ME HAVE A STRAIGHT POLYNOMIAL OPTION 0015 

C 2 We HAVE A SEMI LOG OPTION. LOG OF Y ONLY 0016 

C 3 WE HAVE LOG OF Y AND XI ONLY 0017 

C 4 WE HAVE LINEAR WITH RESPECT TO X3 ONLY, LOG OF OTHER VARIABLES 0013 

_£, „.5. WE HAVE LOG OF ALL VARIABLES - - - — - 0019 

C 6 WE HAVE LOG Or XI ONLY 0020 

C 7 WE HAVE LOG OF XI , AND X2 ONLY 0021 

C 6 WE HAVE LOG OF XI , X2 , AND <3 ONLY 002 7 

C 9 WE HAVE THE RECIPROCAL OF Y , AND LINEAR WITH ALL OTHERS 0023 

c 002'* 

C SAMPLE DATA CARD. USE FIELDS OF TEN COLUMNS EACH- 

c 0027 

<*% *G XI X2 X3 0023 

<V 3A.1 3.9 .42 4. 0029 

c QG3H 

C IF AN ARGUMENT IS BLANK THE PRECEED ING VALUE WILL 3E USED. 0031. 

L THEREFORE, DO NOT USE A TRUE ZERO. ANY VERY SMALL NUMBER WILL ..DO* Q032 

c 0033 

C USE A TAIL CARD WITH A 1 IN COLUMN 41. 

c 0035 

c 0036 

C WE READ DATA AND BUILD MATRIX 0037 

c - 003ft 

DOUBLE PRECISION T(100) , D(100) , F, G 0039 

COMMON Nl, N2 t N3, N4 , N, NP , SYM 0049 

DIMENSION X(4,2), U(100) 0041 

EQUIVALENCE (N123 , N) °04? 

DEFINE FILE ll( 1200, 51, U, IN ) , 1 3( 800, 200, U, IN3) 0043 

UjZ EORMA.I 1..1H1, 413, 2X, 18A4 ) G044 

101 FORMAT ( 1HC, 413, 2X, 17A4 ) 0045 

1 QO FiiRMA T (412, 18A4 ) 0046 

33 READ (1,100) Nl, s\2, N3, N4, (U(K), K = 1,18 ) 0047 

SYM - UUS) 00 <** 

DO 35 K = 1,8 004^ 

35 J<IK»11 = 1. 00-5 

WRITE (2,101) Nl, N2, N.3, N4, (U(K) , K = 1,1 7) 0051 

WRITE (3,102) N1,N2,N3,N4, (U(K) , K= 1,18) 0052 

©N123 = Nl * N2* N3 005 ^ 

NP = iU2 3 SI 0054 

C ZERO THE MATRIX 0055 



DO 8 K_* l,N123 
8 T(K) = 0, 

DO 44 K = I,NP 
44 WRITE (13»KH T(L) , L = 1,N ) 

I = 1 

J= 2 
IN = 1 
GO TO 36 

3 WRITE(ll'IN) IT t (XCK 9 J) # K = 1,4 ) 
GO TO (11, 12, 13, 14, 15, 16,17, Id, 19) t 
19 X(4,J)=1./ X(4,J) 

GO TO 11 

ALGG(X(3,J)) 
ALOG( X ( 2, J ) ) 
AL0G(X(1,J)) 



N4 



ALOG( X(3,J)) 
ALOG( X(2,J)) 
ALOG( X(1,J)) 
ALOG ( X ( A , J ) ) 



FIRST ROW IN THE MATRIX IN U 



18 X(3,J) = 
17 X ( 2 , J ) = 
16 X(1,J) = 

GO TO 11 
15 X(3,J) = 
14 X ( 2 , J ) -= 
13 X(1,J) = 
12 X(4,J) = 
11 CONTINUE 

K =~0 
CALCULATE THE 

C = 1. 

DO 7 NC= 1,N3 
B = 1. 

_DG 6 NB- 1,N2 

a"= i. 

00 5 NA= l,i\l 

K = K fi 1 

U(K) = A*3*C 
5 A = A* X ( 1 , J ) 
6_B_*_B * X(2,J) 
7 C = C * X ( 3, J ) 

U(K£1) = a ( 4 , J ) 
CALCULATE UPDATED MATRIX 

DO 9 M = 1,NP 

READ( 13«h)( T(K), 

DO 10 L = 1,N 
10 T(L) = T(L) I U(L) 
9JWRITE (13'M) (T(K) 

K = I 

I ~ J 

J = K 

36 READ (1,104) X ( 4, J J , 

104 FORMAT { 4F10.3 , 15 ) 
CHECK FOR ZERO ARGUMENT S 
DO 1 K = 1,3 

IF ( X ( K , J ) ) 1,2 tl 

2 X(K,J) = X(K,I) 
1 CONTINUE 
CHECK FOR TAIL CARD 
IF(IT) 3,3,4 
4 WRITE ( 11« IN) IT 



K = I,N) 

* U(tt) 
, K = 1,N) 



xd.j) , xiZt jl, x n, j i 



IT 



THE FOLLOWING IS GIVEN TO HELP YOU UNDERSTAND THIS PROGRAM . CAN YOU 



0056 
0057 

0060 _ 
0061 

006? 
0063 
_P064 
0065 
0066 
0067 

006 B 
0069 
0070 
0071 
007? 
0073 
0074 
0075 
0076 
0077 

007 8 
007^ 
008" 
0081 
.008? 
0083 

0036 
008? 
.008^ 
003* 
009 
0091 
009? 
009"* 
0094 
0095 

0096 
0097 

009° 
009^ 

qicp 

0101 
010? 
0103 

QlLQA 
0105 

01 0~7 
0108 
0109 

jflo 

OTll 



c 
c 
c 



c0 

c 



SOLVE N SIMULTANEOUS EQUATIONS 
NP « Wl 
DO i K j= 1,N 
F = f{K,K) 
DO 1 J = K,NP 
T(K t J ) - T(K, J) / F 
DO 1 I = 1 , N 

IF C I VNE • K ) T ( I , J ) = T{ I , J) - T(K,J) * TU,K) 

SOLVE THE SIMULTANEOUS EQUATIONS 
DO 21 K = 1 f N 



WITH ONLY 7 FORTRAN STATEMENTS 



L = 1 ,N ) 



READ( 13* K ) (D(L) , L = 1,N) 

F = DiK) 

Kl = K E 1 

til) 21 J = Kl , NP 

REaQ( 13 • J) ( T(L) 

T ( K ) = T ( K ) / F 

G = T { K ) 

DO 22 I = 1,N 

IF (I-K) 23,22,23 
2 3 T( I ) = T( I ) - D( I ) * G 
2_2 _CONTINUE 

21 WRITE ( 13 • J ) (T(L), L = 1 , N ) 

00 24 K = 1,N 
24 U(K) = T(K> 
C PUNCH COEFFICIENTS 

105" FORMAT! /X, A4, 1H( , 14, 5X, 4H)~ , E15.8 ) 
WRITE (2,105) (SY*,K,U(K), K ^ 1,N) 

IN = 1 " ~ " 

JH|6 FORMAT ( IX, 5E13.5 , F10.3) 

W7 FURMAT(/6X, 2HX1, 11X, ?HX2, 11X, 2HX3, 11X,2HYG, UX,1HY, 
1 12X, 5HER PC / ) 
WRITE (3,107 ) 

GO T0_ 41 

32 CALL TBiPLY ( Nl, N2, N3, N4 , XI, X2, X3, Y,U ) 

ER = 100. * ( YG - Y ) / Y 
C TABULATE RESULTS 

WRITE (3,106) XI, X2, X3, YG, Y, ER 
41 READ! 11 • IN ) IT, X1,X2,X3 , YG 

IF (IT) 32,32,33 

END 

/* 

// EXEC FORTRAN 

SUBROUTINE TB$PLY ( N 1 , N2 , N 3 , u4, Z 1 , Z2, Z3, F3, C ) 
DIMENSION C( 36) 
XI = Zl 
X2 = Z2 
X3 = Z3 

GO TO (11,11,13,14,15,13,14,15,11), N4 

15 X3 * AL0G(Z3) 
14 X2 = AL0G(Z2) 
13 XI = ALOG(Zl) 
Tl CONT IfiUE 

N = Nl * N2 * N3 
F3 = 0. 
DO 3 K = 1,N3 
F3 = F3 * X3 



0112 
0113 
0114 

~oi is 

0116 

0117 

0118 

0119 

0120 

0121 

012? 

0123 

0124 

012^ 

012* 

01 2 ^ 

0128 

012° 

0130 

0131 

013? 

0133 

0134 

013S 

0136 

0137 

0138 

01 30 

0140 

014! 

014? 

0143 

0144 

0145 

0146 

0147 

0148 

0149 

0150 

015! 

015? 

0153 

0154 

0155 

0156 

0157 

0158 

015« 

016* 

0161 

016? 

0163 

0164 

0165 

0166 

0167 



\ 



F2 = 0. 
BUT J = 1,N2 
F2 - F2 * X2 

Fl =r"-gv"~- 

DO 1 I = 1»N1 
Fl = Fl * XI & 

1 N = N - 1 

2 F2 = F2 £ Fl 

3 F3 = F3 L F2 

GtTTO TZTfTZ t 2 2 , 2 2 , 2 2 , 2 1 , 2 1 , 2 1 1 29 ) , N4 

29 F3 = 1. / F3 



016* 



"GOTO 2 1 
22 F3 = EXP< 
21 CONTINUE 

RETURN 

Enu - ... 

/* 

77 "EXFC tNKEDT 
/* 

7/ FXEC r&$HA0 1 



F3) 



04030101 


ELCO VS 


TVB 


ru ^ - - 


.1.8 


30. 


1.85 


40. 


1.9 


50. 


1.95 


60. 


1.8 


10. 


' " -Z".TT5 


""'3D'. 


2.2 


40. 


2.4 


50. 


2.7 


60. 


1. a 


10. 


2.3 


30. 


• — 7.5T" 


~"""4TT. 


2.95 


5C. 


3.45 


60. 



DS £ USGaI 
150. 



300. 



450. 



X" ~"~4 



CL 
CL 
CL 



CL 
CL 

xr 

CL 
CL 
CL 
CL 
CL 
XL" 



ELCO VS DS S DSGiM 

1 )= 0.22859659E CI 

2 )= -0.65686345E-01 

3 )= G.19246C84E-G2 

4 )= -0. 18875580E-04 

5 -0.31371277E-0; 
"6" )= 0.42 393967F-0 3 

7 )= -0.12535511E-04 

8 )= 0.12892923E-06 

9 ) = 0.30227648E-0^ 

10 )= -0.43952537E-06 

11 )= 0.15635532E-07 

12 )= -0.15259277E-09 



0169 
017" 

OlU 

0173 
0174 

0176 
"0177 ~ 
0178 
0179 
0180 
0181 
018? 

tjtbt 

018A 

0186 
0187 
0188 
"0T89 
019^ 
0191 
019? 
019^ 
0194 
0195 
0196 
0" 

or 

020O 
"0201 
020 *> 
020* 
0204 
020^ 



4 3 1 


1 












TABLE 2. 




ELCD 


VS 


OS 6 OSGN 


XI 




X2 






X3 






YG 




y 




EH PC 


0.10000E 


02 


0. 15000E 


03 


0. 


IOOOOE 


01 


0. 


18000E 


01 


0. 18002E 


01 


-0.011 


0.30000E 


02 


0. 15000E 


03 


0. 


IOOOOE 


01 


0. 


18000E 


01 


0, 1 8002 £ 


Oi 


-0.009 


0.40000E 


02 


0. 150Q0E 


03 


0. 


IOOOOE 


Oi 


0. 


I8 50QE 


01 


0. 18477E 


01 


0.124 


0.50000E 


02 


0. 15000E 


03 


0. 


IOOOOE 


01 


0. 


19000E 


01 


0. 19032E 


01 


-0. 167 


0.60000E 


02 


0.15000E 


03 


0. 


IOOOOE 


01 


0. 


19500E 


01 


0. 19488E 


01 


0.062 


O.IOOOOE 


02 


0.30000E 


03 


O.IOOOOE 


01 


0. 


laoooE 


01 


0. 1 7994E 


)1 


0.031 


0.30000E 


02 


0.30000E 


03 


O.IOOOOE 


01 


0, 


20500E 


Oi 


0*2Ct>29E 


01 


"0. 144 


0.40000E 


02 


O.iOOOOE 


0.3 


0. 


IOOOOE 


01 


0. 


22000E 


01 


0.21967E 




0. 149 


0.30000E 


02 


0.30000E 


03 


0. 


iOOOOE 


01 


0. 


24000E 


! 


0.24CKKE 


01 


-0.017 


0.60000E 


02 


0.30000E 


03 


0. 


iOOOOE 


01 


0. 


27000E 


Oi 


0.2 ?004£ 


01 


-0.015 


0. iOOOOE 


02 


0.45000E 


03 


0. 


IOOOOE 


Oi 


0.18000E 


01 


0. 18004E 


01 


-0.023 


0o30000E 


02 


0.4500DE 


C3 


0. 


iOOOOE 


01 


0. 


2 3'JOOE 


01 


0.229621: 


01 


0*. 164 


0.40000E 


02 


0.45000E 


03 


0. 


iOOOOE 


01 


0. 


2570GE 


01 


0.23 7691 


01 


-0*2 68 


0.50000E 


02 


0.45000E 


03 


0. IOOOOE 


01 


0* 


29!>006 


Oi 


0.29454E 


01 


0,157 


0.60000E 


02 


0.45000E 


03 


0. 


IOOOOE 


Oi 


0. 


34500E 


oi 


0.345UE 


01 


-0.031 



IJT219I 
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USER EXPERIENCE WITH 1130 LP-MOSS 



An Abstract 



U. S. Reduction Co. has used the 1130 LP-MOSS application package 
since its first release. Various problems have been encountered during 
its use; however, useful answers have been obtained. Due to the size of 
the aluminum alloy blending problem being studied, a second 1130 had 
to be leased for full dedication to this problem. Early results indicate 
a reasonable payback may be obtained from this hardware and software 
combination. 



An Outline 



1. Company background 



2. 



Early uses of linear programming 



3. 



Problems encountered in implementing 1130 LP-MOSS 



4. 



Results to date and future planning 



5. Specific application modifications desired 



APPLICATION OF SIMULATION IN CONTROL, DESIGN, AND 
OPTIMIZATION OF CHEMICAL PROCESSES 



M.J. Shah 



ABSTRACT 

The problem of supervisor/ control and optimization of a chemical process 
requires that the control as well as the optimization programs be provided with a 
mathematical relationship between the dependent and independent variables in the 
process. 

In this presentatjon we will discuss methods of arriving at this relationship 
based on the fundamental laws of physics and chemistry. We will make the proper 
approximations valid for control purposes to obtain the solution of the differential 
equations, describing this relationship. Use of simulation languages helps in 
reducing the programming time as well as the number of. trials required to attain 
successful solutions. 

An example of methanol plant will be discussed in some detail to illustrate 
the mathematical and programming techniques to achieve the desired relationships 
for control and optimization. It will be shown how these differential equations with 
modification of the objective function when used in the optimization program can 
lead to optimum design of the plant . 



Paper to be presented at the Common User's Meeting, San Francisco, 
December 11-12, 1967. 



INTRODUCTION 

i In the early applications of digital computers for controlling chemical pro- 
cesses, the work performed by the computers was limited not only by the restricted 
capability of the computers, but also by the fact that control and optimization 
techniques had not been achieved by personnel of the chemical plants. Much time 
and effort was spent in data gathering, alarm scanning and limit checking of 
important plant variables. Since the interrelation between the plant variables was 
not too well known, or in many cases not defined mathematically., virtually all of 
the control work was done by using so-called regression models' derived from plant 
data gathered by the control computer. These regression relationships were 
generally simple enough that computer control could be achieved without overtaxing 
the capability of the available digital computers. 

More recent digital computers in the process-control field are much more 
powerful in their computing capabilities. They also provide some very useful ready- 
made programs for performing the various control tasks in a plant over and above 
the normal logging, alarming, and scanning functions. These programs will be 
discussed in subsequent sections. 

It is important to realize that a control computer must operate in a continuous 
mode, just like the chemical process it is controlling. The computer thus must 
perform all the routine data logging, alarm scanning, and limit checking functions, 
plus the functions of supervisory control, direct digital control, optimization, 
engineering simulation and other desirable tasks. 

In this paper we will discuss the various process control tasks of a control 
computer and, in particular, the use of simulation — off-line as well as on-line — 
in control, optimization and engineering design calculations of a chemical plant 
with a process-control computer. The discussion will, needless to say, relate to the 
available softv/are for the IBM 1800 Control System, although the technique is not 
limited to any particular control computer. 
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Figure 1 shows the various functions which the presently available IBM 

control computer performs. The central executive program is the time-shared 

3 

executive system (TSX) . This program allocates the processing time available for 
the various functions which a control computer is required to perform. The time 
allocation is done in an optimum fashion, in that the calculations which have the 
utmost importance have the highest priorities. There are twenty-four or more levels 
of priorities available on a computer, allowing any higher level priority calculation 
or computer function to interrupt a lower priority level function or calculation which 
is being carried out at a given time. The interrupted calculations are not destroyed, 
but stored in the core or on an auxiliary memory storage such as a disk. Thus, after 
the higher priority calculations are completed, the lower priority calculations 
which were interrupted are resumed at the point where they were interrupted. When 
any priority interrupt calculation is completed, the computer seeks for lower and 
lower priority calculations, until the interrupt calculations are completed. At 
that time, it is available^ for offline nonprocess calculations or it is in idle mode. 
A core clock is provided to perform routine functions such as data logging and 
report generation at specified time intervals. The limit checkup of plant variables 
(violation of upper or lower limits) is done by a comparator, and the normal computer 
calculations are not interrupted unless a limit is violated, and specific computer 
processing action is required as a result of the variable limit violation . 

COMPUTER FUNCTIONS 

■ Let us look at the various functions and steps in process control that are 
performed by the computer. 

Data Logging and Management Information 

As soon as a computer is installed,, it is used for data logging and management 
Information such as production of a particular chemical in 24 hours, the amount of 
fuel used, etc. The logged data is also important in model verification which will 
be discussed in subsequent sections. The importance of obtaining reliable plant 
data for model verification cannot be overemphasized. The computer is much more 
reliable for logging than a human operator. Furthermore, a programmed filter (such 
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as time averaging, exponential smoothing, etc.) can be used to sort out the 
instrument signal from noise. Other routine functions such as alarm messages and 
emergency operator action sequence can be handled as a first step in computer 
control. 

Regulation 

A second function which a computer performs is regulation. The easiest 
regulation is by means of an operator guide which is defined as a sequence of 
control action messages to be taken by the plant operator when disturbances or 
upsets in certain plant variables are detected by the computer. To cite an example, 
a cement plant had a set of four kilns of identical design, all fed by a single raw 
material slurry feeder and burners using a single fuel . Each kiln was controlled by 
a single operator for every shift. From a total of twelve operators, two were able 
to control their kilns in the best manner. It is easy in a case like this to program 
within the computer the sequence of actions which the best operator takes as a 
result of the disturbances. This sequence of instructions is printed for all operators 
to follow when similar disturbances occur. In this manner, the operation of all 
kilns reaches the level of best operator performance. 

Supervisory Control 

In a normal plant operation, the operator makes changes in set-point positions 
for one or more control loops when a disturbance occurs. For a chemical plant with 
a large number of control loops, there are unavoidable interactions between con- 
trol loops. An experienced operator can handle two to three loop interactions and 
make simultaneous changes in set points of the loops to bring the plant to a desired 
level of control . It is difficult, if not impossible, for the operator to handle more 
thgn three loop interactions. On the other hand, a digital computer can be pro- 
grammed to adjust one or more of the set points simultaneously by solving a set of 
equations which relate the variables of the plant to the multiple set points (target 
variables). A typical equation may look like equation 1 . 



= Fj AT + F 2 AM + F 3 AU + F 4 AVj + F 5 AV 2 



0) 



where Fj , f^t ^3 etc. are constants, T is the target variable to be controlled, 
M is the manipulated variable, U is the uncontrolled (disturbance) variable and 
Vj / Vg, Vg are other measured variables which enter from interactions with other 
loops. Thus, for interacting loops a set of equations such as equation 1 is solved to 
control a set of target variables. 

In this manner the computer can not only handle multiple-loop interactions, 
but also make the changes in a consistent manner. In addition, since each loop has 
different dynamic characteristics (slow or fast response, short or long dead time, 
first, second or higher order system), each set-point adjustment can be carried out 
by the computer in such a manner that different dynamic characteristics of each 
individual loop are taken into account. Although this technique is in no sense an 
optimum dynamic control scheme, it is, because of its practical value labeled a 
poor man's dynamic control scheme. Figure 2 shows how this scheme works. Let t 
be the time at which the computer calculations require that cn adjustment of set points 
from say 60% of scale to 80% of scale. The adjustment may be made in several 
steps of time intervals. Let us say that the interval between two adjustments is At 
and the full adjustment is to be carried out in five steps. If the loop response is 
fast, the adjustment can be performed in five equal increments, or any combination 
of unequal increments which make the total shift of 20% scale. For a sluggish loop, 
one can provide incremental steps which includes overshoot as exemplified by the 
dotted line in Figure 2. If there is a dead time involved, one may incorporate a 
delayed action adjustment for the set point. 

In certain areas of the plant, it is possible that one or more control valves 
are changed manually, and no analog feedback controllers are provided. The 
computer can perform the adjustment of these valves via a stepping motor if adjust- 
ment equations for changing the valve positions are programmed in the computer. 
Thus, the supervisory control can also provide a direct computer control (DCC) of 
the plant valves. As opposed to direct digital control (DDC), the DCC function 
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only provides proportional control and at more prolonged intervals (1 minute or 
more). DDC takes only seconds. 



SUPERVISORY PROGRAM 

The various functions described above, routine data logging, alar m scanning, 
limit checking and operator action as a result of limit violation, programmed 
operator guide control, supervisory control and direct computer control can be 
performed with an IBM program known as PROSPRO/1800 (Process Supervisory Pro- 
gram for 1800). The details of this program are in reference 4. 

In brief, PROSPRO program is written in such a manner that virtually no 
programming knowledge is required on the part of plant personnel. However, the 
program requires that personnel know the behavior of the plant thoroughly, and, 
more important for our discussion, that relationships for interacting variables in the 
plant be written in mathematical form. A general type of relationship is available 
within the program, and one only needs to fill in the value of constants in the 
general adjustment equation. 

PROSPRO requires that each variable in the plant be uniquely identified by 
a number. Then, for each variable, six standard information sheets are filled out. 
Two of the six sheets, the variable information sheet and the adjustment information 
sheet, are shown in Figure 3. Most of the required information is given by entering 
a or 1 in certain columns, giving values of limits, actions as a result of violating 
these limits, and so on. The adjustment equation relating the variables of the plant 
is linear; however, the values of the coefficients Fi , F^ ... may be calculated 
by using a general type of nonlinear equation such as 

Fj =A+B[C + (F k /D)] E ^ * (2) 



where A / B, C, D and E are values of constants to be supplied by plant engi- 
neers. Once the six sheets are completed for each variable, the information from 
the sheets is transferred to punched cards and read in PROSPRO as data . The sheets 
provide permanent documentation and an/alteration in information on one or more 
variables is carried out by altering the corresponding sheet and the data card, and 
reading in the new card in PROSPRO. Some of the features and capabilities of 
PROSPRO are outlined in Table I. 1 



DIRECT DIGITAL CONTROL 

In some chemical plants, it may be desirable to install a digital computer 
instead of analog controllers, especially when a new plant is being built. This is 
commonly referred to as direct digital control. It is important to note that a digital 
computer can not only perform the function of analog controllers such as proportional 
derivative, and integral control, but also the more sophisticated control functions 
such as nonlinear control, control of loops with fixed dead time and variable dead 
time, adaptive gain tuning, and so forth, at no additional cost. Analog control 
devices which perform these functions can become prohibitively expensive as the 
number of loops requiring sophisticated control increases. In addition, a digital 
computer performs the routine logging, alarm scanning, and limit checking functions 

Direct digital control on a chemical plant with an IBM 1800 is attained by 
the standard program, DDC/1800. Again, for details of the program and control 
techniques, refer to refernce5. < \_-J ^ 



OPTIMIZATION 

Although significant benefits are achieved by using digital computer control 
for better plant regulation, improved product quality , and reliable plant information 
for operating personnel and management, it is felt that a substantial additional 
benefit can be achieved by means of optimization, especially in petro-chemica! 
plants. Optimization is defined as maximization of plant profit by means of con- 
trolling the plant target variables in such a way that the constraints on all plant 
variables are satisfied. All chemical plants are dynamic in the sense that the 
constraints on the variables are always moving. It can be shown mathematically 
that the optimum operation of the plant shifts as a result of shifts in constraints. 
For example, the maximum heat load on a heat exchanger using cooling water may 
depend on the amount of cooling water and its temperature, the extent of fouling 
in the heat exchange tubes, and so on. The heat load constraint may limit a multi- 
stage compressor load if the heat exchanger is used for interstage cooling of the gas 
being compressed. Any change in heat load capacity of the heat exchanger will 
affect the optimum operation of the plant. 

To define optimization in real time mathematically, let Xj , x 2 , • x^ 

be a set of independent variables (generally set-point positions or valve positions) 
and yj , y^, y 3 • • • v m be a set of dependent variables (temperatures, pressures, 
, flow rates, heat load, compressor load, etc.). Let y^ be a profit function 

yj = f, x 2 , x 3 ... x n , y 2 , y 3 , y 4 . . . yj (3) 

and let y 9 , y~, y be functions of x. and y • . 

£. o n i ^ i j j 

y 2 = f 2 (x 1 , x 2 , x 3 . . . x n , y 3 , y 4 , y^ . . . yj (4) 

J 

y 3 = f 3 (x ] ,x 2 ,X3 ...x n ,y 2< y 4 , X 5 • • • yj (5) 

and so on . 
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The optimization is performed by selecting a set of x. which maximizes the 
function fj subject to the constraints . 

X 1L <X 1 <X 1U 

j 

X 2L <x 2 <X 2U ^ 



x , < x < x ,, 
nL n nU 



and 



y 2L <y 2 <y2u 

>'3L < >'3<y3U & 



ymL<ym<ymu 

where subscripts U and L indicate maximum and minimum values, respectively . 

• 

The mathematical problem of optimization may be further complicated by 
imposing additional constraints; that is, one or more x and y may have an upper 
or lower limit which should be respected most of the time. Furthermore, plant 
experience may dictate that a certain independent or dependent variable should be 
close to a particular target value most of the time. These two types of constraints 
are defined as soft and target constraints, as opposed to hard constraints defined by 
equations 6 and 7. Mathematically, a cost penalty is invoked for violating upper 
or lower limits. In case of target constraints, a penalty is imposed for deviation on 
either side of the target. 
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Plant experience may dictate a minimum move on x. , in order to avoid 
unnecessary disturbances which cause regulation problem, offsetting a small gain in 
profit as a result of the move of the independent variable by the optimizer. This 
is defined as a dead zone. 

A program, designed to perform online optimization with a control computer 
taking into consideration, hard, soft and target constraints, dead zones, and non- 
linearity of the plant behavior, is now available for the IBM 1800. This program is 
called the control optimization program (COP/1800). 

It requires a program written either in FORTRAN or assembly language 

called MODL0 which calculates the value of y^ , . . . y m from a given set of 

x. values. The optimizer calls the program MODL0 to calculate a gradient matrix 

g^- at a starting point x. Here x and y are the vectors of independent and 

dependenr variables. The numerical evaluation of dy/dx is carried out with a 

different value of Ax. for each i to avoid difficulties because of differences in 

i 

dimensions of individual x. 's. Equations 3-5 are then approximated by linear ex- 
pansion in a 'linearity limit' which is larger than the value of Ax. for each i. 
With linear programming technique, a linear optimum profit is calculated which 
satisfies the various constraints imposed on the optimizer. The set of optimum x.'s 
are then used to calculate a corrected nonlinear profit y^ which is compared with 
the previous value of y^ . If the profit shows an increase, a new gradient matrix 
dy/dx is calculated at the new set of x. and the above procedure is repeated. 
Several features are included in the optimizer to help avoid the well-known 
occurrence of polymodality — one such feature being the adaptive linearity limit. 
Experience indicates that the best procedure to avoid getting trapped into a subopti- 
mum is by judicious selection of the ratio of linearity limit to Ax. for each i. 
The ratios may be obtained by performing optimization off-line on the computer, 
using various values of these ratios. See references 2 and 10 for details on the 
program and techniques employed. 
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SIMULATION 

In the discussion of control so far, it has been implied that the relationships 
between the variables within the plant are known in the form of equations 1 and 2 
for supervisory control and in the form of equations 3 through 5 for optimization. 
A chemical plant, in general, is quite complex and, in many instances, these 
relationships have not been developed by plant personnel. An alternative is to 
obtain the relationships using some sort of regression analysis on the plant data 
collected in the initial phases of the computer installation. 

It Is much better, In my opinion, to simulate the process offline on a digital 
computer by writing down the equations describing the physical and chemical 
phenomena occurring in the plant, and then solving these equations with the aid of 
the computer to yield the relationships in the forrrrof equations 1 through 7. The 
digital simulation can be performed during idle time of the control computer (Fig. 1 , 
block IV) as a nonprocess program or preferably on an offline computer several 
months prior to installation of the control computer. In either case, there are 
several computer languages which could be used for this purpose: FORTRAN, 
CSMP (Continuous System Modelling Program) and DSL (Digital Simulation Language). 
The latter two are especially useful to engineers, since they are oriented to the 
mathematical language of process engineers. 

Simulation of a process also has some added benefits. An engineer who has 
relatively little experience in the plant behavior can get 'hands on' training on the 
sensitivity of the plant to changes in certain variables with the aid of the simulation 
equations, provided that the equations do represent the plant behavior with fair 
accuracy. Furthermore, the range of changes in the simulated plant can be much 
larger than that observed in day-to-day drift in the plant. Often, the simulation 
may indicate a plant operation significantly beyond the normal operating point, 
with higher plant throughput or product quality . In any case, the reliability of a 
good simulation model is much better than the reliability of a model generated by 
regression equations. 
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The rest of this paper, then, will deal with simulation model development 
for the purposes of supervisory control and optimization of the process. 

MODEL DEVELOPMENT 

i 

On examining a process under consideration for simulation, one finds that, 
in general, large numbers of units are involved in a plant, and it is virtually 
impossible to carry out detailed mathematical analysis for each unit. The desire is 
to obtain, ultimately simple mathematical relationships which can perform control 
and optimization calculations with a control computer in real time. It is then 
necessary to select for detailed analysis those units in the plant which are most 
important from a profitability standpoint and those units which are difficult to 
regulate. The other units may be capacity limiting and can be simply hgndled QS 
constraints. 

A mathematical model of a chemical plant unit generally consists of differ- 
ential equations describing: 

1 . Material balance 

2. Energy balance 

3. Pressure balance 

The material balance equation may involve chemical reaction as well as 
diffusion, whereas the energy balance may involve heat of reaction. For all the 
three balances, the standard form of equation in qualitative terms is 

Input - Output = Accumulation + Generation (or Depletion) (8) 

The 'generation' term takes into account the formulation or disappearance of a 
reactant in chemical reaction and heats of reaction. 
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For steady state, the 'accumulation' term is zero. The nonsteady -state case 
gives rise to the so-called 'dynamic models.' Dynamic models are useful in pro- 
cesses which have a long residence time for the material in the plant unit. Manu- 
facture of cement in a kiln is such a process. When the residence time is short, 
the steady-state models are adequate for representing the process. The dynamic 
models in most cases consists of a set of nonlinear simultaneous partial differential 
equations which are difficult to solve even on large digital computers. The steady- 
state models are somewhat easier to solve since they give rise to ordinary differential 
equations. In this paper we will deal only with the steady-state case, because 
most significant units in petro-chemical plants have short residence times for the 
throughput material. 

In th is paper we will illustrate the various steps involved in developing a mathe- 
matical model for on line optimization and supervisory control of a methanol plant. 
The type of plant analyzed here employs high-pressure catalytic reaction 

CO + 2H 2 CH 3 OH 

and the pressure is generated by means of a high-speed centrifugal compressor 
driven by steam turbines. 

% We will show how simulation helps in developing online relationships for 
controlling the plant. 
< 

Figure 5 shows a simplified diagram of the plant. There are two sections: 
one is the reformer and the other the synthesis loop. In the reformer section, natural 
gas is reacted* with steam to yield CO and C0 2 . 

CH 4 + H 2 CO + 3H 2 

CO +'H 2 rtr^: C0 2 + H 2 
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CC>2 is removed from the reformed gas after heat is recovered 3n the waste heat 
boiler and the gas mixture containing h^, CO, CH^ and small amounts of CC>2 is 
fed to compressor . Often, some amount of is added to the natural gas in the 
reformer to have a more favorable chemical equilibrium for CO. The gases after 
compression to 3500 psig or more are mixed with a recycle stream and sent to the 
synthesis converter where methanol is formed. The product gases from the converter 
are cooled and liquid methanol is removed in separator tanks and led to a distillation 
train for purification. Part of the gas from the separator tanks Is purged and the rest 
is fed to the recycle wheel of the compressor. 

First of all, three plant units, namely, (1) primary reformer, (2) methanol 
synthesis converter, and (3) compressor are important from a computer control 
standpoint . 

Compressor Control Problem 

The compressor has two control problems. Steady-state analysis of the com- 
pressor yields horsepower requirements (and hence steam requirements in turbines) and 
pressure to the methanol converter, whereas the dynamic analysis is necessary for 
surge control. With the help of plant data or compressor curves supplied by the 
compressor manufacturer, one can design a simple control scheme for spill-back 
valve control in compressors to avoid violation of surge limits. A simple scheme is 
described by Magliozzi^ wherein the surge limit line on the compressor curves 
is linearized and a controller is designed to avoid the surge. The same scheme can 
be expanded by fitting a polynomial relationship to the surge line, and a control 
algorithm can be written to perform nonlinear surge control functions by means of a 
digital computer. 

The simulation of the compressor is used in conjunction with the model of the 
synthesis converter to predict compressor load. 

We will briefly discuss the model development of three units used in 
methanol plants; for a detailed analysis, see reference 7. 
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Synthesis Converter 

This unit is the most important since the production of methanol takes place 
here. Apart from the reaction of methanol formulation, other side reactions occur 

at high temperature, the most significant being the formation of ether 

! 

CO + 3H 2 CH 3 OCH 3 

In figure 6 we show a simplified diagram of the converter. There are several 
catalyst beds and a heat exchanger. For each bed the material, energy and 
pressure balance equations are 



JI = f 2 (N CQ , N H2> OH , T, AH (T, P)) (10). 



5T = p o- az . (">. 

z is the tube length, and AH is the heat of reaction . Pq is the gas pressure at 
the entrance of each bed . The functions fj and ^ are highly nonlinear and, 
because equations 9 and 10 are interdependent, they must be solved numerically. 
Furthermore, as pointed out in reference 8, the solution of these equations for the 
entire reactor poses a trial and error problem due to the fact that the temperature 
boundary conditions for the first bed are dependent on reactor product temperature, 
a classic example of a two-point boundary value problem. 

It must be pointed out that the differential equation model for the reactor 
(equations 9 through 11) is not suitable as an online optimization relationship, 
because of the long time required for the solution. Since for our purpose it is only 
desired to relate converter exit temperature and methanol production to temperature, 
pressure, and composition of feed, a number of simulation runs are made on the 
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differential equation model, and the results of the model are fitted to simple 
polynomial type relationships using regression analysis on the results. The solution 
of equations 9 through 11 must, of course, agree with any available plant measure- 
ments of temperature and composition at the reactor exit. Any discrepancy between 
plant data and model results can be reduced by adjusting kinetic parameters and 
heat-transfer coefficient values, since these^are not known too accurately in the 
model. Once the online relationship for the reactor is obtained from simulation 
results, we are ready to combine with the model of the rest of the plant. 

Compressor Capacity Relationships 

As indicated earlier, and in reference 8 , the compressor model is developed 
from the compressor curves relating polytropic heat to flow rate with compressor 
speed as a parameter. The efficiency curves for each stage may be fitted in the 
same manner to flow rate. 

The pressure calculation for each stage is then carried out by using the 
standard equation 

k-E 

(W (k-1) 1 \ k-l C 

02) 



where H is the heat developed at stage n, E is the efficiency, R is the ratio 
P 

of heat capacities at constant pressure to heat capacity at constant volume, and 

and T^ are pressures and temperatures of gas entering stage n. C n and C n+ j 
are compressibility factors for entrance and exit gases in stage n. 

Compression horsepower requirement is given by 
W • H 

Horsepower = — 550""^ ^ ^ 

where W is the gas flow in lbs/second. 
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The gas temperature at the exit of stage n is given by 

r n+1 = T n • (P n+1 /P n • c n+] /c n 



T n + 1 = T n • ( P n + /Pn • C + ,/CJ ^ (14) 
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The separator section model is again of a simple form 

Moles gas in liquid methanol = (N.)^ = a. + b. p + c. T (15) 

and 

Moles methanol in gas = (N ^) = d + ep+fT + gT (16) 

me g 

This completes the model for the methanol synthesis loop. 
Refo rmer 

7 

The reformer model uses the kinetics of Moe CO and are assumed to 

reach chemical equilibrium whereas the formation of CO. from CH, and H 

o 

is dependent on kinetic rate . As indicated by Shah, the following equations are 
obtained on the basis.of these assumptions." 

< N CH 4 > = f 3^xlt' P exlt'< N H 2 0> ' ^CH* > < 17 > 

exit reform inlet inlet 

< N H 2 0> _ = f 4 ( T exif P exit' ( N H 2 0> • < N CH > > < 18 > 

exit reform inlet inlet 

Fuel required = FU = ^ (Tj n , et , (19) 

Stoichiometric equations subsequently give values of h^/ CO and CO2 
moles at the reformer exit from equations 17 and 18. 

Equations 9 through 18 represent simulation of the most important units of the 
methanol plant, namely, the synthesis converter, compressor, separator, and the 
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reformer. The absorption unit generally removes 99.5% of CCX,/ and the 
various heat-exchanger simulation uses standard heat-transfer equations. 

The next important problem is how to use the various simulation models to 
derive the profit equation for the plant in the form of equations 3 through 7. 

A selection of independent and dependent variables, their constraints, and 
cost factors is required at first. Table II shows a list of the independent and 
dependent variables. 

The stream composition of gas entering the synthesis reactor is treated as an 
independent variable, simply because experience suggests that the synthesis loop 
the plant bottleneck which cannot be overcome easily. The compressor make-up 
steam , flow, end composition are thus treated as dependent variables, and the 
only independent variables in the reformer are exit temperature (set point) and 
steam-to-natural gas ratio in feed. This selection of independent and depen- 
dent variables also makes it convenient from a calculation standpoint, since the 
trial and error problem as a result of the recycle steam in synthesis loop (which 
arises if the compressor make-up steam is treated as an independent variable) is 
eliminated. 

The profit function calculation for optimizing then follows the steps listed 
below: 

1 • Calculate converter exit temperature and composition, based on feed 
rate, temperature and pressure. 

2. Calculate heat load on the hear exchanger of the boiler feed water. 

3. Calculate temperature of product entering separator. 

4. Calculate vapor-liquid equilibrium and hence vapor and liquid 
composition in separator. 

5. Calculate recycle stream, purge gas flow, and composition. 
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6. Calculate make-up steam to compressor, compressor horsepower, and 
pressure to synthesis converter. 

7. Calculate natural gas required for make-up stream and composition 
(initial guess) . 

8. Calculate reformer exit composition and correct natural gas requirement, 
if CH^ and r^ do not agree with the make-up stream requirement. 

9. Calculate profit function as follows: 

/j = Aj (Methanol production) - ^ (Methanol loss in purge) + (Heat 
recovery in boiler feed water heater + Waste heat boiler + reform 
boiler) - A^ (Natural gas to reformer) - A^ (Fuel) - A^ ( Steam to 
compressor turbines) - A^ ( Steam to reformer) . 

We do not wish to present a detailed discussion on the optimization results. 

8 

Briefly, the optimizer pushes the plant to one or more of the following constraints: 

1 • Maximum compressor horsepower (shaft horsepower or steam availability 
limiting horsepower) . * 

2. Maximum cooling water flow rate in heat exchanger prior to 
separator tank. 

3. Minimum steam/gas ratio. 

4. Maximum reformer exit temperature. 

5. Maximum waste-heat boiler capacity. 

SUPERVISORY CONTROL EQUATIONS 

We will illustrate the method of obtaining control equations, similar to 
equation 1 for use in supervisory control with PROSPRO as applied to the reformer. 
As pointed out in reference 9, the reformer control is based on maintaining exit 
temperature and percent of methane in the gas to a certain level. The equations 
relating the exit temperature and percent methane to steam feed and burner fuel 
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flow in the reformer are quite complex (equations 17 through 19). However, in 
the plant operating range, these equations may be linearized. 

F 1 A(% CH 4 ) = F 2 A(l/steam flow) + F 3 A(l/exit temp) (20) 

A (Exit temp) = F^ A (Fuel) - F^ A (Gas temp inlet) 

-F^ A (Steam inlet temp) (21) 
-Fg (Inlet gas flow) - F Q (Inlet steam flow) 

The value of the coefficients Fj through F Q are derived from simulation 
runs around the operating point by fitting the simulation results to equations 20 and 
21 . If the sampling rates for measuring exit methane concentration is fast (infrared 
analyzer), one can improve regulation by including in equations 20 and 21 past 
values of the changes in the variables, appropriately weighted. 

Comparing equations 1 and 20, it is obvious that the target variable T is 
percent of CH^ in the exit gas, and the manipulated variable U is the steam flow. 
In equation 21 , exit temperature is T and fuel flow is U. Equations 20 and 21 must 
be solved simultaneously to affect feedback control of the reformer. 

-Similar equations can be written for the methanol synthesis converter, heat 
exchanges, and purge control in the synthesis loop. 

APPLICATION TO DESIGN 

In the above discussion we have illustrated the use of simulation in deriving 
control equations for supervisory control, as well as developing a model profit- 
function for plant optimization (COP) . 

It may be desirable to make changes in the plant unit during the course of a 
computer control project. Plant optimization with COP, for example, may indicate 
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a heat exchanger, or reactor as a bottleneck because It is underdesigned . The 
computer then can be utilized for redesigning the plant unit in an optimum manner. 
Either the available simulation languages or FORTRAN can be used for simulating 
the process unit. The basic simulation equations are generally the same for design 
as well as operation. However, in plant simulation the design parameters such 
as reactor area and length are constant, but the flow, temperature, and operating 
conditions are variant. In design simulation, one needs to vary the design parameters 
for a given set of operating conditions. With a change in the independent and 
dependent variable definition, the control optimization program can be used for 
optimizing the design of a plant unit. The profit function which is maximized will 
in this case be the negative value of the design cost, so that a minimum cost will 
be obtained. 

SUMMARY AND CONCLUSIONS 

In this paper we have described the various steps involved in the application 
of a digital computer control on a chemical plant. We have described the various 
functions that an IBM 1800 performs with the assistance of an executive program 
which performs optimum allocation of computer processing time to these functions 
on a predetermined priority basis. We have also described the standard IBM soft- 
ware available for performing some of the functions. 

To attain the maximum benefit with a digital computer, the use of simulation is 
described in deriving the necessary supervisory equations for the controller and 
profit equation for the optimizer. An example of a methanol plant is given to 
illustrate the use of simulation in deriving these equations on the basis of fundamental 
laws of physics and chemistry. It is also shown how the same simulation model can 
be applied to design and even to optimizing a plant unit design. 

It is to be emphasized, in conclusion, that all these functions can be and are 
being performed with an 1800 on various chemical plants around the world, pro- 
viding an optimum utilization of control computers. 
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Table I PRGSPRO System Summary 



Standard fill-in-the-blank programpriing 
forms 

Compatible supervisory control configu- 
ration 

Incremental feedback and feedforward 
control action 

Multitype and multivalued process vari- 
ables 

Consistent processing procedures and 
interprogram communication 

Versatile logic, calculation, and conver- 
sion routines 

Advanced interacting and sequential con- 
trol capabilities 

Streamlined program modification and 
documentation 



Table n 

List of- Independent and Dependent 
Variables for a Methanol Plant 



Independent Variables: 



Dependent Variables: 



c 10 



'12 



l 13 



*14 



k 15 
C 16 
c 17 



Total moles feed to converter 

H 2 /CO ratio In converter feed 

CH 4 /CO ratio in converter feed 

cold split 1 in converter 

cold split 2 in converter 

cold split 3 in converter 

boiler-feed water rate to heat exchanger 

cooling water rate to cooler before separator 

compressor speed 

water rate to compressor intercooler stage 1 
water rate to compressor intercooler stage 2 
water rate to compressor intercooler stage 3 
water rate to compressor intercooler stage 4 
Steam to gas ratio in Reformer 
Fuel rate to Reformer 

Fraction purge gas sent to reformer as fuel 
Damper control in reformer stack 



= profit, which Is a function of methanol production, heat 
recovery in boiler feed water heater, H 2 loss in purge, 
cooling water cost, etc. 

y 2 = purge rate in separator 

y^ = inlet temperature to converter 

y„ = cooling water temperature exiting various heat exchangers 
4 

v v v v = constrained temperatures at the exit of catalyst 
"6* 7' 8' 9 

beds 1,2,3 and 4 



y 10 

y ll 

y l2 

y 13 

y 14 

y 15 

y l6 

y 17 

y 18 

y 19 

y 20 

y 21 

y 22 

y 23 

y 24 

y 25 



product temperature exiting boiler feed water heater 

water temperature exiting boiler feed water heater 
= temperature of product entering separator 
= pressure at separator 

pressure at outlet of recycle wheel of compressor 
= total flow in compressor make-up stream 

H 2 /CO ratio in make-up stream 
= CH 4 /CO ratio in make-up stream 
= Total horsepower requirement for compressor 
= % CH 4 in reformer exit gas 
= % C0 2 in reformer exit gas 
« Reformer exit gas temperature 
= Reformer Furnace box temperature 
= process gas feed to Reformer 
= steam required for compressor turbines 

% C0 2 exit CO z absorber 



VARIABLE INFORMATION SHEET 



PEEP CONVERSION (PRODUCT COHCtNT<,A,TlON) 

7a, narr va.ui/c tAi.(m.«,Tc> PV &'Q>3a 



7 8 10 



012 



A.g.-.'.o.3 . .c «.n.vcr sn ] Identification used for Message Output. 



P C T . lEngineennt Unit* uied for Console Display. 
iLproceiVUnit of Variable. |0«CD, 1 « f ? ? T ' M " V 2 « Next Unit) 



2ii Grid /Co lumn /Row ■ Console Grid Position. 

S^OjX|Q f i ,«> Tj Rputine Processing Interval / Proceeding Sequence. 



! 5> ) Number of Routine Values u»ed to determine Average Variable Value. 
| fa] [J Is Avg. Value used for Reference. Delta and Deviation checks 7 ( I « Yes) 
Current Value Processing: 
ills Variable a Measured Input ' ( 1 « Yes, following 7 Items applicable) 
Is Inp ut continuously monitored for MAX-MIN Limit Alert? (1" Yes) 



3 3 I Measured Input A ddress. 

Top of Scale. 



Bottom of Scale, 
jv "Option in Conversio n Eq. ( 1 * Yes) 



ADC Value Conversion Equation: 

Converted Value "B + C 
Note: 



ADC - a 



Bias (B) 
6 7 [Coefficient (C) 
Calculate Current Value, Convert TC Input or Adjust Conv. Value. 
Intermediate Special Action. 



Thermocouple input converted by 
specifying preassigned code in 18 



Limit Checking and Special Actions: 



2il 



2 !9 



3- O O 3 2 



(No Viol 
(Viol.— -No Viol 



]Assi-ned Process MAXIMUM Limit. 
Viol. ) ) Special Action taken when pas sing through 
.}/ the Assigned Process Maximum Limit. 



I .0,2.0.9 



to -| A»»igned Process MINIMUM Limit. 
(No Viol.— »Viol. ) 1 Special Action taken when passing through 

.No Viol.). I 



(Viol. 



the Assigned Process Minimum Limit. 



jUpper Special Action Reference Point. 



(Below —.Above) ) Special Action taken when passing through 
(Above -» Belo w) I the Upper Reference Point. 



jLower. Special Action Reference Point. 



(Above — »Below)i Special Action taken when passing through 
(Below_Above)/ the Lo*er Reference Point. 



3 • 'A s signed Delta Limit for Operator Notification, 
j (No Viol. — .Viol.) Special Action taken when Delta Limit exceeded. 



p elta required for a Predictive Adjustment Action. 
J Action taken for a Predictive (Delta) Adjustment. 



Target Value and Deviation Processing: 

Does V ariable have a Target? (1« Yes, following 10 items applicable) 

Minimum Time betAeen successive Target Calc. and/or Dev. Adj. 



; 0.1^3. Sp ecified Anio n to evaluate New Target Value. 

5.'~l *.**it;ped Deviation Limit for Operator Notification. 
! . . 1 (No Viol. — .Vio l.) Special Action taken *hen Dev. Limit exceeded. 



75P ev '- vt ' on required for Normal Adjustment Action. 
7 p) Action taken (o r Normal Deviation Adjustment. 



^Maximum Set Point Adjustment per pass, 
j Srt Point Output. (1« Controller, 2 s DDC, 3« Operator Message) 

. ) Computer Set "Controller / DDC Address. 
] Set Point Movement Rate. ( I - M.x. rate, I * 1/2 Max. 
Final Special Action. 



3 - 1/3 Max. .etc.) 



Figure 3 . Variable information sheet 
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ADJUSTMENT INFORMATION SHEET 



\ 5 

\l\2Q.l b\ 



ma nipui^tc d wh iak c_ -_pu R>f *c e_ ounr ucr TC M pchat y_RC_ 



FFE0BA>CK. gCQQC5T - CONVCW^IOM ; FerDFOP.W*.V.P RCqueST- TEEPRAtTE 

Adjustment Equation: = FjaT + F^aM* F3 A U + F4 A Vj ♦ F5 A ♦ F A V3 
Target - Currcnt(Average) Current(Average) - Last Bate 

Calculated Adjustment 1 ' or U (Uncontrolled) Variable 

Interacting Control Information. (Omit if single equation solution) 

7 8 10 14 16 20 22 26 28 32 34 

ZD Ul . . . 1 \Z\ . . . 1 QrU-soliition acceptable ?(l»Yes) 



UU EC 



0. 



Definition and Development Of Terms in Adjustment Equation. 

Defines Value of Coefficient F n . (-nnnn, lnnnn, 3 nnnn or Blank 4 ) 

Identifies Process Variable. 

7 8 10 1 14 16 *Const. F n Coeff. 28 






1 










3 





4 


0^ 


0|6 







10 , 


, 14 


-;o. 


^° ' 




' ,0. 


.4.3 






i . . . 



Adjustment Equation Output Restr 

3° 



30 




. 33 


2 


O 




2 


o.a.e 


2 


0.6.3 


* ' ■ 




* ' ' 



T - Targeted Variable 
M- Manipulated Variable 
U - . Used for Predictive 
V,. ' Adjustment and/or 



r 
v,- 



v,- 



Simultaneoua Equation 
Interaction!. 



10 1 9 6 



1 • o t 71 



2;2 O04 



ctions. 

Action taken when Variable M Out of Service. 
Action taken whe n Variable M Off Computer (On Operator). 

I o .J Maximum allowable adjustment to M per pass. 



Action taken when Target of M already at MAX-MIN Limit. 
Adjustment Reference List for Partial Loop Test. (2 nnnn or Blank) 
If Entry 14 specifics a Reference List, Entries lS-*8 specify subListe 
I (-1, -2, -3, -4) referenced for all subsequent M's in control loop. 
1 If Entry 14 is Blank, Entries l5-i8 specify all of the subsequent M 
. . , Variables in control loop. 

_jls Target of M set to Average instead of Current for Partial Loop? (I* Ye») 
Manipulated Variable Adjustment ( a M) Output Control. 

HED C 



7 8 10 %T 14 %aM 



PoJTIME in minutes (bXXXX) or as developed (-nnnn or lnnnn). 
%T 



. .0 


, ,5 





(1) 


.2.0 


. .7 


5 


U) 


5 O 


." .2 


5 


(3) 






(4) 



Cumulative elasped time from present time 
f expressed as a percent of TIME. 

1 % t,M- Percent of A M change made after %T time. 
' (Note: Negative % AM is permissible.) 



2 3 
2(4] 

Special Action Initiated Upon Significant Change in Manipulated Variable (M). 



7 8 10 Initiating M Change 22 2 1 Actinn 
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3 4 



3 5 



3 lb 



o 2 2 



Action may be specified as follow*: 

(a) Process Variable Special (Onann). 

(b) Execute Ccneral Action (lnnnn).**" 

(c) Feedforward Request Call of 

Adjustment Equation (2nnnn). 

(d) Execute Special Program(3nnnn). •* 
♦♦Calculated aM in Result Register. 



Figure 4 Adjustment information sheet. 
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NATURAL GAS 



STEAM to a; 2 w 
S \ COMPRESSOR,- 1 
1 1 TURBINES 



INTERSTAGE WATER COOLERS 



R2FORMLR 




STORAGE 



LETDOWN 
TANK 



SEPARATOR 



BOILER FEED 
WATER HTR 



METHANOL 
CONVERTER. 




Figure .ta 
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COMMON User) s Meeting 

San Francisco Meeting December 11, 12, 13 

Laboratory Automation '* 
by Ray Edwards 1<*>rt 

The session on Laboratory Automation will include a general description 
of programming and equipment aspects of the application of 'the 180Q and 
1130 to this newly emerging and fast growing field. Following this 
discussion, an application will be discussed in detail. This will include 
a description of the type of research to be accomplished, the incentives 
of the on-line computer, the programming system to run the instrument 
in a closed loop fashion, and other experiences to date with the system. 



DESIGN PHILOSOPHY 
- SYSTEM OVERVIEW - 

APPLICATION MONITOR 

Executes Procedures in Specified Seq. 

PROCEDURES " 

Handles a Specific Task (e.g. Sort) 

PROGRAMS and SUBROUTINES 
All Written in Fortran 

Lowest Level Routines do General Purpose Functions 



DESIGN PHILOSOPHY 
- SYSTEM OVERVIEW - 

CORE ORGANIZATION 

Standard Compiler Allocation 

Two Sections: COMMON and WORK REGIONS 

DISK ORGANIZATION 
Single External File 
Each Record One Sector Long 
Files Use Simple String Method Via Regions 
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1130 

MONITOR 



XEQ 



MOSS 



MOSS 



Initialize 

Core 
Common 



MOSSM 



Application 
Monitor 



NO 



Execute New \ 
Procedure 



Return to Monitor 




DISK 
Common 



Proced 
Called 



j re 
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DESIGN PHILOSOPHY 
- PROGRAMMING STANDARDS - 

COMMON. . . 
O K = FIXED POINT 

Q - REAL 

VARIABLES... 

I = INDEXES 
L = LENGTHS 
J - REGIONS 
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4SI 



PROCEDURE FLOW 



CALL DOWN LIST 
(THRU INPUT) 

MOSS 
INPUT 

OVER-WRITE CALL DOWN LIST 

CNV1 

CNV2 

OVER-WRITE CALL DOWN LIST 

CLEAN 

SORT 

SORT3 

OVER-WRITE CALL DOWN LIST 

CLN2 

SORT 

SORT3 

OVER-WRITE CALL DOWN LIST 
Etc. 



CALL EXECU (LINK1, LIN KL, LEVEL, KREPT)* 
GO TO jjjjj* 

GO TO kkkkk* 

Position in Call Link Array of First Program 
to be Moved [(3-4n) where n is control Call Link] 
Position in Call Link Array of Last Program to 
be Moved [-(1+4M) where M is Last Link in Array] 
Recall Indicator [if Level = must return to main] 
Provides Re-entry control [Used in Computed GO TO] 

jjjjj - Statement Number of First Call Link in ARRAY 

Statement Number of Statement Following Control 
Call Link 



linki - 

LINKL - 

LEVEL - 
KREPT - 



kkkkk - 



- READ-WRITE DISK - 



DREAD (NREC, J) 

Read a Disk Record (NREC) into Region (J) where 
NREC - 2048 * J + Record Number 

DWRIT(NREC.J) 

Write a Disk Record (NREC) into Region (J) where 
NREC = 2048 * J + Record Number 

DREAD (KNDCT, J) 

Read the First Dictionary Record 
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OTHER PROCESSING FILES 

KMTX - - MATRIX FILE 

1. Derived from SETUP 

2. Scaled for Processing Accuracy 

3. Contains: 

a) Explicit Equation Coefficients - 

b) Implicit Row Coefficients 

KVLST - - VARIABLE STATUS LIST FROM SETUP 

1. Derived from SETUP 

2. Contains: 

a) Name 

b) Type 

c) Matrix File Element Seq. Number 

d) Scale Factor 

e) UB and LB For Each Variable 
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OTHER COMPUTATION FILES 

ETA FILE 
Formed by INVERT 

Represents Inverse of Basis Variables 
An ETA Matrix is added by Each Minor Iteration 
On Each Major Inversion KETA is reduced bgck 
to Single Entry 

a) Minimize ETA File 

b) Increase Accuracy 

- BETA FILE 
Formed by INVERT on Last Step 
Contains: 

a) Post Inversion Activities of Basis 

b) Post Inversion Activities of Bounds 
Values are Scaled 
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OTHER OUTPUT FILES 



KSLTN-- SOLUTION FILE 

1. Formed by LPSOLUTION 

2. Contains: 

a) Status List 

b) Matrix File Objective Entry 

c) Basis Activity 

d) Reduced Cost 

3. Values are Scaled 

KIANL - - INTERMEDIATE ANALYSIS (LPANAL) 

1. Used In Conjunction with KMTX and KVLST for LPANAL 

2. Contains: 

a) Increase - Decrease Cost 

b) Basis 

c) Activity Increase - Decrease 

3. Values are Scaled 
KWRK1-9 - - VVORK FILES 

1. Used for Transient Data 

2. Some Used by System, Some Not 



TO RUN LPMOSS 
WITH FORTRAN COMPILER AND 
ROOM TO WORK IN 



{MONITOR 
// DUP 

* Define Void Assembler 

* Define Fixed Area 0100 

* Storedata CD FX LPMSS 1778 
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PROGRAMS STORED IN FIXED AREA 



ON LPMOSS DISK 
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3o call DRfTATy (j.rZ-;Ubf?xu) 



G o To 10 



So 7^ 



. 6 



Lag i c <? ) FIcca J> jj>j 



(|>/>CF 

'It, PCF 



V Zegio^ /via. 



G-o To 2.S 

too £:y 1c J of SUu<?/rf> ft) i j \ L 

< (3) /^^/U> /AJT6 REQ)cyi JFI. 

JFr RcTuAdCfc By f,C(*2c>H Cotton iy .Us cp ' ~~ 

jr/r j- FI : - v. *?es**jj Fi/APiy Physical E&ar rzsr 



/ 



xSfe-Arr 4<r Last f?EGro'J To Usr. 



c 
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INTRODUCTION 

This is a report on work at the Esso Research Laboratories of Baton Rouge 
which added three more disks to the TSX system. The additional drives are treated 
in an identical fashion as the existing three drives. The new system has been tested 
for some of the options of TSX and all known bugs have been corrected. It is easy 
to convert an existing TSX Version 3 system into a six drive system. All that is 
required is a TASK assembly, the STOREMD of four subroutines, a partial system load, 
a define operation, and a skeleton rebuild. Although the method of distribution 
has not been decided, these changes are to be made available to other 1800 users. 

DISCUSSION 

The Esso Research Laboratories are located only two blocks from the main 
office building of the Humble Oil Refinery at Baton Rouge. Work at the laboratories 
is mostly process development. A small computing center is maintained in the laboratory. 
Through the years this has changed from a C.P.C.,to a 650, to a 1620, and will be an 
1800 when program conversion is completed. Large computing jobs are sent to the 
refinery 360 system. A study of work done by the labs computer showed it to be data 
acquisition and batch processing of small jobs. This finding led to our 1800 order. 

Logic of handling the acquired data indicated that some form of indexing 
and a random access to the files are desirable. Hence the choice of disks for mass 
storage. Ifowever, data volume is such that three 2310 disks are insufficient. Our 
system was ordered with five drives. A similar situation exists in the refinery 
where an 1800 computer is being used for direct digital control of a blending opera- 
tion. Here the system was ordered With six disk drives. Under the press of two 
urgent applications, I began the job of modifying TSX to support the three additional 
disk drives. I was assisted by our I.B.M. representative, Mr. J. A. Albritton (S.E.). 

I.B.M. was very cooperative and through Mr. Rob Martin of the Houston .". 
DACS Center we were able to get copies of 1*+01 microfiche tapes of the TSX system. 

The work was started in May and completed in September. The modified system 
has been in use since October. There are no known bugs remaining in the six drive 
TSX. Although all of the options of TSX have not been tested such things as skeleton 
build, core load build, compiling of Fortran and assembler language programs, storing 
and deleting of core loads and relocatable programs, and the execution of process and 
non-process programs have been done. 

Humble has consented to make these results available to other 1800 TSX users 
once the method of distribution has been selected. The Esso Labs would prefer not 
to act as agent for handling the distribution. 
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We started from TSX 3 Mod 1 with corrections through PTF 27 • Appendix B 
shows the source level changes that we made to TSX. It should be noted that card 
numbers correspond to the microfiche tape for Mod 0. This is because only Mod 
was available when we started. As Mod. 1 and PTF's through 27 became available we 
added, them to our Mod source decks. 

Our work was aided greatly by the fact that in some areas of the TSX programs 
provisions were made for future expansion to six drives. In particular, the Monitor 
and Disk Utility Programs (DUP) record and test the availability of drives by the 
use of three bits of a word in DCOM. Since a word has 16 bits, additional bits were 
available for three more drives. Even more important was the embedding of unused 
wrds in DCOM whenever information referring to a particular drive was stored. 
Without these provisions it would have been necessary to modify and enlarge DCOM. 
DCOM is the heart of TSX and is referenced absolutely and repeatedly throughout the 
routines. Furthermore several system programs end only a few words from the start 
of DCOM and enlargement would require moving them to lower core. Such moves would 
be difficult to organize in sections of EDP and DUP where an extensive overlay 
structure has been built. In fact, without the unused words of DCOM, it would not 
have been practical to change TSX for six drives and because of this it is not 
feasible to consider support of more than six drives. 

It is difficult to convey the size of a Job of this kind. It took over five 
months and involved twenty-seven TSX routines. Fourteen pages of source changes are 
listed in Appendix B. TSX logic in handling the disks was sufficiently general that 
only in a few cases was the logic changed and often, even then, just for a gain in 
efficiency. MDst of the changes or additions were minor. But the problem of locating 
them was not necessarily small. It sometimes involved tracing back through several 
routines and to do this required a great deal of detail knowledge of the TSX programs. 
Because no courses on TSX internals are offered by I.B.M., we were forced to learn 
the system by reading programs. 

Instructionsooutlining the procedure to be used in converting an existing 
three drive TSX system into a six drive system are given in Appendix A. It is briefly 
to (l) insert the change cards in source TASK and reassemble, (2) STOREMD the four. 
Fortran 1/0 subroutines, (3) partial system load the changed routines redoing the 
assignments and the DEDIT , (k) define WDISK and CONFG, and (5) rebuild skeleton. The 
define and rebuild skeleton must be done with six drive TASK in core. The defane 
CONFG and skeleton build are required because a new cold start and an error decision 
program, have been stored. Word count and sector address of skeleton are stored to cold 
start by define and to EDP by skeleton builder. 

CONCLUSION 



Other potential users of our six drive modifications face two problems. 
They are the problems of distribution and maintenance of an IBM unsupported system. 
Corrections to TSX have been numerous and many are in the twenty-seven routines which 
we changed. If updated source programs are available, it is usually easy to make the 
corrections and recompile. However, most 1.800 users do not have source cards, which 
are available only on magnetic tape. 

EBS/gth 
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I, General Comments 

A. These decks represent user modifications to TSX to support six disk 
drives. Three drives are standard and three are RPQ devices. 

B. Area Codes of 20, 2k, 25 and IAC codes of 20, 2k, 25 are required. 

C. The cards consist of source change cards for TASK and object decks for 
subroutines and. for system routines. Control cards are included. 

D. After the partial system load, user TASK is required. The system is 
now incompatible with Sys Gen Task. 

E. Assignments must be made for the 3 additional disk drives. A DEDIT 
is required to clear FLET. A DEFINE CONFG and a skeleton rebuild are 
required. 

F. Three additional fields are used on the cold start card {2k, 26, 28) 
for dive identification and on the JOB (21-25, 26-30, 31-35) for label 
identification. 

II. Procedure 



A. Complete the additional TASK EQU's. Insert the change cards replacing 
cards with equal numbers and including others in the source TASK cards. 
Reassemble TASK. 



B. Copy your system on another pack. Henceforth use the copy. 

C. Do the DUP operation required to STOREMD for the four subroutines. 

D. Do the partial system load. Redo the ASSIGNMENTS and DEDIT to initialize 
FLET. If the three additional disks have not been assigned, be sure to 
assign them. (From here on user's TASK from Step A is required). 

E. Load user's TASK from cards. Do a DEFINE CONFG. (ignore the error message 
which says TASK in core is not the same as TASK on disk). 

F. Rebuild skeleton using the new SKA program and the Level 1 SKB program. 
EHS,JAA/gth 
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MATERIAL LIST FOR 
SIX DRIVE CHANGES TO I.B.M. 
1800 TSX-PHASE 2, 18O0-OS-O01 
VERSION 3, MODIFICATION LEVEL 1, THROUGH PTF 27 

USER MODIFIED TO SUPPORT SIX DISK DRIVES 
(Esso Research Laboratories, Humble Oil Company, Baton Rouge, La. 
and I.B.M. , Baton Rouge, La.) 



WRITE UP OF PROCEDURE 
CARDS 

" """" Deck Ident . 

Item No . Description Quantity (Col. 73-75 ) 



1 Task (Source change cards to be 339 TSK 
inserted in source task) 

2 Supervisor 80 NPS 

3 Core Load Builder 83 CLB 
k Cold Start 51 CLD 

5 Disk Utilities (Total - 1*42 Cards) 

(1) Control 18 DCT 

(2) Let/Flet Dump 17 LFD 

(3) Store Control Card U3 SCT 
(k) Delete 25 DEL 

(5) Dump-Disk to NPWS 19 DPI 

(6) Write address 9 DWR 

(7) Search Program Name Table 11 SRP 

6 Error Programs (Total - 85 Cards) 

(1) Control Program 38 EDP 

(2) Disk Error Program 11 DSK 

(3) Error Table k EUD 
(k) C.E. Routine A ik CEA 
(5) C.E. Routine B 18 CEB 

7 Skeleton Builder 60 SKA 

8 Task Utilities 

<l) Task Card to Disk 10 TRL 

(2) Task Disk to Card 12 TDD 

(3) Task Disk to Patch 7 TDP 
(k) Task Disk Duplication 6 TUP 

(5) Task Disk Load for Off -Line 

System 13 TDL 

(6) Task Write Address % 33 TWA 

9 Subroutines (Total - 31 Cards) 

(1) F-I/O Busy Test 5 BT1 

(2) Disk F-l/0 Busy Test k BT2 

(3) Disk F-I/O 17 MDI 
(k) Fortran Find Routine 5 MDN 



APPENDIX B 

SIX DRIVE SOURCE 
LANGUAGE CHANGES 
TO TSX 
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APPENDIX B 
jTSX. MODIFICATIONS TO SUPPORT.. 

SIX DISK DRIVES 
.SO.imCE„LMGmGE..<:HMGE__C.MDS_ 
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„00RG3-EQU- 
D0RG4 EQU 

_DORG5_.EQU. 
PR I L3 EQU 

_-BRi.L4_EQ.U- 
PRIL5 EQU 

DC__ 



DC 
DC 



XADQ. 



LOGDR 

___„_P_HYDR. 

DBSUR. 



TADDS 



DC 

_DC 

DC 

_D.C 

DC 

..DC 

DC 

.DC 

DC 

.DC 

DC ! 

.DC 

DC 

.DC 

DC 

..DC 

DC 

XLC 

DC 

DC 

DC . 

JD_C_ 



_20__ 

IN3 

24 

~IN4 ~ 

...25 

IN5 
..TADDSG:.6 

TADDSCr 1 
XADDS67.__ 

TADDSG- 1 2 
_5 

-6 



0- IF— .THREE-D-ISK-DRv-ELSE— 1~ — 
IF FOUR DISK DR ♦ ELSE 1 

0— IF- FIVE— D I SK-DR • - ELSE- J 

DISK DR 3 INTER. LEVEL * 0/23 
DISK._DR-4_JNT.ER#_ LEVEL— *-D/Z3_ 
DISK DR 5 INTER. LEVEL * 0/23 
AD.D.I-T.I.ONS__T.O.JAC__T.ABLE_ 



..TADDS 

*&5 

XA_ 

TA1*D0RG1 
..IA2 *D0RG1 *JDORGa 



DK JDR V TAB. _ADD__T_ABl.E 

ADD OF LOGICAL DRV TAB 

ADD.. OF ..PHY S I C Al DR TAB 

END OF PHYSICAL DR TAB 
COD.E_„OF...LA.S.I_D IS K_DR.V__ 
MINUS MAX NO OF DRIVES 

FW A_OF._ DEVICE XA B-l 

DK DRV TAB ADD TABLE 
LOGLC.A I DR.I V E_0_ ... 



-TSKOOOai— 
TSK00082 
JT_SK0a083_ 
TSK00084 
.XSK0Q0.a5-_ 
TSK00086 

TSK.0I.6Z1_. 

TSKO 1672 

.T_»K0_1673_ 

TSKO 1674 

TSK0J.675-- 

TSKO 1676 

_L87_.TS.K0 3 79 Q_ 
188 TSK03800 
1_8.9_XSK0381Q.__ 
190 TSK03820 

Jj_L„TLSK0383Q_._ 
192 TSK03840 

.1_93_. TSKO .385 Q_ 



TA3*D0RG1*D0RG2*D0RG3 ' 

XA4*D0RG 1 *D0RG2*DQRG3_*D0RG.4 

TA5*D0RG1*D0RG2*D0RG3*D0RG4*D0RG5 

„TA P_H_YJ5_l.CAI DP.LV.E_Q 

TA 1 *D0RG1 

T.A2*D0RG1 *00RG2 . . _ 

TA3*D0RG1 *DORG2*D0RG3 
_TA 4 *DO.R Gl .*D OR.G 2* DOR G 3 *D.ORG 4 



DC 

_CDRSP...EQU 

TA33 BSS E 

F_FA_ EQU 

ORG 

*_IN S.ER X.. -t H E_ 



TA5*D0RGl*DORG2#D0RG3*DORG4*D0RG5 

...DRS.UP-C ON D I SPL ACE ME. NT FROM __CQN 



_X.A33.r_T A 2 



FFA*D0RG2*D0RG1&TA2 
FOLLOW I NG.._222. CARDS . AF.TER.__TSK0.7.4J.Q. 



TSK03901 

X.SK0.3902_ 

TSK03903 

XSK.03 9.0.4 

TSK03905 

_T_SK03906 

TSK03907 

..TSKO 390 8._ 

TSK03909 

TSK0390A 

TSK0390B 

XSK0390C_ 

TSK0390D 

X.S.K04 2.41 

TSK07390 

XS.K.0.740P 

TSK07410 



J ABLEL.E0R. .DR.I.VE . 3. 



* 

XA3l. 



.D.< 
DC 
_DC_ 
DC 



JO 

/AOOO 

_0_ 

/AOOO 



L ASZ_I DC. C %ARE.An. 



NEXT 



^CONTROL- 
IOCC. % A RE A a 



, _ .DC _ ._ 





DC 





* DC 





DC 





DC... 


_ 


' DC 


/A400 







DC 


/A700 


DC 


T A3 6 36.. 


DC 


/A600 


DC 


0._.„ 


DC 






.LAST. 
LAST 



^CONTROL- 

WD CT 

DK ADD 

. isl EXT_ W D -CT_ „ 

NEXT DK ADD 
.SEEK._I.OCC. %AREAP 



ERL00001 

ERL0.00.02.. 

ERL00003 
..Q.„ERL0.0004_ 
1 ERL00005 
_2._ERL00.0Q6_ 

3 ERL00007 
..4.-ERL00008 

5 ERL00009 
.6_-ERLO0ai0_ 



7 ERL00011 

8_.ERL00012. 
9 ERL00013 



..ERL000.14. 



%CONTROlo 
__SENS.E_.I .Q_C_C_._.._ ..SEEK .T0.___.„1 Q. 

%CONTRO_n 11 ERL00015 
C H E C 'r> I A B L E„_XQC C_.%AREAa_JL 2_JERL.O 01 6. 

%CONTRO_D 13 ERL00017 

-_TPTAL_.WD_.C_T LEFT 1.4„ERL00018 

FIRST READ/WRITE ' 15 ERL00019 
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.SOURCE . LANGUAGE. CHANGE .. CARDS 



Page 2 of Ik 



DC 
DC 
DC 

J>C_ 



DC 

DC. 

DC 

DC. 

DC 

__DC. 

DC 
DC 



* INDICATOR 





_.__.P 



.0. 

-2 

JA3&16. 

T A 30 17 

„ 

-8 

. 0. _._ 



. .750 

TABLE 



SAVE 1 



SAVE 2 



DC_. _ 





DC 





DC 





DC 







0. 


DC 





.DC. 





DC 





DC 


1 


DC 





.DC 


.0. 


DC 





_DC 


p_ 


DC 





_D_C__. . 


0. 



VARIABLE 6-2 

SAVE. ADD 

SAVE ADD 6 1 
NEXT.. ARE A__ADD_ 

ARM POSITION 

ERROR CT 

CALL I NT LEVEL 
....NONPRO CESS _ WORK 

NEG-ON 
1.1 

SEEK 
...CH TAB 

SEEK FUN 

..„.WZRBC 

GENERAL 
FILE PROT 

IND OP 



6_L 



STORAGE 

EVEN—OFF 

. 1.2 

WRITE I MM 

CH__T_AB_RET_ 

READ 

„ W / R BC I .N_ OP. 

INDICATOR 
. F I LE. PRO. SW. . 
FIN OlD OP 



16 ERL00020 
JL7_ JERLOpp^l_ 
18 ERL00022 

.J9._ERL00O.23_ 
20 ERL00024 
21...ERL00025 
22 ERL00026 

_2_3_.EBL.OQJ02_7__ 
24 ERL00028 

.25...ERL00029. 
26 ERL00030 

.27 E.RLQ0.031 

ERL00032 

_28 . ERL0P.033. 
29 ERL00034 

. 30„ERL0 0.0.35 



.I/.P_.^R^A._llPR.__CHEPK._TABLE_. 



FIRST IOCC 



Ct L.EFT 



♦ DISK 



TA44 
FAC 



DC 

..DC „„.. 

DC 

_QC___ 
DC 

DC 

DC 

DC 

DC 

DC 

DC 

DATA 
DC 

DC 

DC 

DC 

DC 

.DC 

DC 
DC 
DC 

DC 

DC 

DC 

BSS 

EQU_ 

ORG 



/A70 1 

_ 





1600 



PRIL3 





*G 1 

/A600 
TABLE — SECTOR 
'. 11 ^ 





_.._P 







P___ 

o 

„ ; „ 



_ 

E 



FIR ST WD CO UN J. 
FIRST DK AD 

... EJ RST . TOT AL WD. 
SENSE/RESET 

...RELAT IV E AR M , POSIT I N_ „ 
FILE SWITCH 

SKIP. ARM . POSI TI.ON. .CHECK 
NONPROC WK ST END ADD& 1 

. NOT USED YET 

DISK INT LEVEL 

$ I O SET I NO I CATOR 

CALL ADDRESS 
TABLE R E AD IOCC 



TABLE 'WORD COUNT 

SECTOR A DJD RES S 

PACK LABLE 

F. I R ST . S E C PR O WK ST P 

LAST6 1 SEC PRO WK STO 

MOD IF I CAT ! ON LEVEL 

FIRST BAD CYL ADD 



..S E C OND . BAD.CYL, ADDR_ 
THIRD BAD CYL ADDR 

NOT USED YET _ 

NOT USED YET 
NOT USED YET 



31 ERL00036 
.32 ERLpQ P 37„ 

33 ERL00038 

34 ERL00.039. 

35 ERL00040 
.36 ERL0.00.41 

37 ERL00042 

.38....ERLP0.043_.. 
39 ERL00044 
40... ERL0P045._ 
41 ERL00046 

_4 2 E RL 004 7 
43 ERL00048 

.44 . . E R L 00 _4 9_ 
45 ERL00050 

46... ERL 00051 

47 ERL00052 

.48. ERL0P05.3 
49 ERL00054 
5P„.ERL0.0C55 

51 ERL00056 
52. ERL00057 

53 ERL00058 
ERL00059_ 

54 ERL00060 
..^„.E.BkQP_p6_l ._ 

56 ERL00062 
57_ERL00063.__ 
58 ERL00064 

59. ERL00065 

60 ERL00066 
A .1 ERL00067 



TA44-TA.3 . 

FAC*D0RG3*D0RG2*D0RG 1 6T A3 



TABLE FOR DRIVE 4 



62 ERL00068 

63 ERL00069 

64 ERL00070 

65 ERL00071 
ERL00072 

ERL0P073 

ERL00074 
ERL00075 
ERL00076 
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APPENDIX B 

— ... : . .. TSX..M)DIFICATIC !JS JO SUPPORT. - 

JSX disk raref 

_ . g OURCS. .LANGUAGE . (UUiNGE -CARDS 

-T-A4 DC : L AST - 1 OCC —% AREA 

DC /COOO %CONTROLD 
DC O NEXT-IOCC _%AREAn 

DC /COOO 5SCONTROLO 
DC 1_ A S I_WD_.CX. ... 

DC LAST DK ADD 
DC .NEXT WD._.CT . 

DC NEXT DK ADD 
DC SEEK IOCC _.%AREAn, _ 

DC /C400 %CONTROLn 
DC S.E N S E .10 C C &_.SE EK_I Ql 

DC /C700 %CONTROi_n 
DC TA4&36 CHECK__T.ABLE_.I OCC. %AREAD. 

DC /C600 %CONTROLD 
— DC T.OT.AI WD-.CT- LEFT. 

DC FIRST READ/WRITE 

DC 

DC — — -SAVE 2— 

DC ! 

DC. - -2- _ VARIABLE. &-Z 

DC TA4M6 SAVE ADD 

DC T A 4 fir 1 7 SAVE.. .ADD 6 1 

. DC NEXT AREA ADD 6 1 
DC -8 ARM _ROS.LT I ON 

DC ERROR CT 
DC 0. CALL INT. LEVEI 

DC 750 NONPROCESS WORK STORAGE 

* INDICATOR TABLE NEG— ON EVEN-OFF 

DC II 12 
DC SEEK WRI TE. I MM.... 

DC CH TAB CH TAB RET 
DC .0 SEEK. F.UN READ 

DC W/RBC W/RBC IN OP 
. DC. .0 GENERAL I Np j CAJOR 

DC FILE PROT FILE PRO SW 
__ DC _Q I ND....OP F I N_.Qt-D_.OP 

DC 1 I/O AREA FOR CHECK TABLE 

DC FIRST IOCC 

DC . FIRST WD COUNT 
D_C_ Q FIRST PK AD 

DC FIRST TOTAL WD CT LEFT 
DC. /C70 1 SENSE/RESET _ _ 

DC RELATIVE ARM POSITION 
DC _0. EI LE... SWITCH 

DC SKIP ARM POSITION CHECK 
DC .._-.._1600 NONPROC WK ST END ADO&t 

DC NOT USED YET 
PC PR. I L 4 D I SK I. NT L E V E L_ 

DC $10 SET INDICATOR 
L DC- . __C.ALl ADDRESS . 

DC TABLE READ IOCC 

DC /C.6.0.0. __ _ 

#D!SK DATA TABLE— SECTOR 
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-0 



ERL00077 
ERL00078 

ERL00079 
-ERL00080- 
ERL00081 
ERL000.82_ 
ERL00083 
ERL00084 
ERL00085 
ERL00086 
ERL00087 



26 
27 

28 



_.1.0„E.R.L 00-088 

1 1 ERL00089 
...12-ERL00.090 

13 ERL00091 
.14 ERL00092 

15 ERL00093 
-J.6l-ERL 0-0094 

17 ERL00095 
-18...ERL00096 

19 ERL00097 
.20. ERL00098 

21 ERL00099 

.-22..ERL00100 

23 ERL00101 
_24 .ERL0010 2 

25 ERL00103 

ERL00 104 

ERL00105 
ERLOO ! 06 
ERL00107 

.29_._ER.L0.aiQ3 

30 ERLOO 109 

...31.. ERLOO 110 

32 ERLOO 1 1 1 

. 33...ERL00.1 1 2 

34 ERL00113 

_35 _.ERL.00.1.14 

36 ERLOO 115 

...37. ERLOO 116 

38 ERLOO 1 17 

._39_ERL001J8 

40 ERLOO 1 19 

_.4. 1 _ ERLOO. 120 

42 ERLOO 121 

...43 ERLOO 122 

44 ERLOO 123 

__4.5...ERL0 0.1.24 

46 ERLOO 125 

. 47 ..ERLOO 126 . 

48 ERLOO 127 

_49 ..ERLOO 128 

50 ERLOO 129 

-51-.ERL00..13.0. 

52 ERLOO 131 

„53 ERL.QQJ.32_- 

ERL00133 



~— TSX MDDIFJCATIONS TO SUPPORT- -~ — 

SIX DISK DRIVES 
-SOURCE LANGUAGE -CHANGE -CARDS- 



DC IT ~ TABLE WORD COUNT 54 ERLOO 134 

DC _P_ SECTOR . ADDRESS 55 _ ER.L.O 0.1 35 

DC PACK LABLE 56 ERL00136 

_ • ■ —DC- FJ RST SEC _PRO WK_...STO . _„ 57. . ERLOO 137 

DC LAST6 1 SEC PRO WK STO 58 ERL00138 

_™ DC. _J0. . ■■ MOD.IE.i.CATJ_ON-LEV.E! 519_-Ee.L0.QjL3_9- 

DC FIRST BAD CYL ADD 60 ERLOO 140 

DC. .0 . SECOND BAD.C.YI A DDR 6 L..ERLOO 14 1 .. 

DC THIRD BAD CYL ADDR 62 ERL00142 

-DC 0_. NOT. ...USED ..YET l6.3_. ERL0 0. 1 .4 3_ 

DC NOT USED YET 64 ERL00144 

DC Q NO T_U S.E Q__YEX 65_.ERL 0.0X4.5. 

TA55 BSS E ERL00 146 

..FAD EQU. .... _T A55.T.T A 4 _ _ _ ERLOO 147... 

ORG FAD*D0RG4*D0RG3*D0RG2*D0RG16TA4 ERL00148 

* _ ERL0Q.Jl49.__ 

* TABLE FOR DRIVE 5 ERLOO 150 

.Jt . . ERL00.15.1 

TA5 DC LAST I OCC % ARE An ERL00152 

DC. /C800... %C0NTR0i_n 1. .ERLOO 1 53 

DC NEXT IOCC %AREAn 2 ERL00154 

DC /C 8 0. . % CONTROL n 3 _ ERL _QX5.5_. 

DC 0- LAST V/D CT 4 ERLOO 156 

.DC L A ST. DK ...ADD. 5.._.ERL 00 157_._.. 

DC NEXT WD CT 6 ERLOO 158 

DC __0. NEXT. ..DK... ADD. 7_ _ERL00 ;159_.„ 

DC SEEK IOCC %AREAn 8 ERLOO 160 

DC /.CCO 0_ . '._ % C ONT R.Q.L 9..ERL0 J 6_1 

DC SENSE IOCC & SEEK TO 10 ERL0C162 

DC /CFOO _ % CONTROL. 1 1 ERLOO 1 63__ 

DC TA5636 CHECK TABLE IOCC %AREAD 12 ERLOO 164 

DC /CEOO _ % CO NT RO L U 1 3 ERLOO 165 _ 

DC O TOTAL WD CT LEFT 14 ERLOO 166 

.DC. F I RST RE AD/.WR I TE 1.5 . ERLOO 167 .. 

DC SAVE 1 16 ERLOO 168 

.DC_ „.. „. LI.„EeL0pX69_ 

DC SAVE 2 18 ERLOO 170 

DC _ . . 19 ERLOO 171 

DC -2 VARIABLE £~2 20 ERLOO 1 72 

DC TA5M6 SAVE ADD 21 ERLOO 1 73 

DC TA5617 SAVE ADD61 " 22 ERLOO 174 

DC NE XT AREA A DD..6 1 23 _E R L 00 l_7 5_ 

DC -8 ARM POSITION 24 ERLOO 176 

.DC ERROR CT 25. ERLOO 1 77_ 



DC CALL I NT LEVEL 26 ERLOO 178 

DC ._ 750 NONPROCESS WORK STORAGE 27 ERLOO 1.79. 

INDICATOR TABLE ' NEG-ON EVEN-OFF ERLOO 180 

DC 1.1 : .12. 28„.ERL00X8X 

SEEK WRITE I MM 29 ERLOO 182 

CH TAB _ CH T AB RET 30 ERLOO 1 8 3 

SEEK FUN READ 31 ERLOO 184 

W/R8C _ W/RBC I N Op .32 ERLOO J 85, 

GENERAL INDICATOR 33 ERLOO 186 

F I LE PROT_ F I LE_PRO SW _ 34 ERLOO 187 

" IND OP FIN Oi_D OP 35 ERLOO 188 

■I/O AREA FOR CHECK TABLE 36 ERLOO 189 

37 ERLOO 190 



DC 





DC 





DC 





DC 





DC 





DC 





DC 





DC 


1 


DC 






4% 
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DC FIRST IOCC 38 ERL00 191 

DC 39-ERL00 1 92— 

DC FIRST WD COUNT 40 ERL00193 

DC .0 .F_IRST.DK AD _..L_ERL00..1.9..4 

DC FIRST TOTAL WD CT LEFT 42 ERL00195 
DC __ZCF.01 SENSE/PRESET _43„..,ER.L 0.0 1.96 

DC RELATIVE ARM POSITION 44 ERL00197 
DC F.I LE . SWITCH 45_ERL.OO 1 98 _ 

DC SKIP ARM POSITION CHECK 46 ERL00199 
DC _ NONPROC WK ST END ADD6£_ 47 ERL00200 

DC ~ "~ NOT USED YET * " 48 "erl 06201 
DC JPRIL5 PI S K _ . J N T_ LEVEL 49 ERL00202 

DC SIO SET INDICATOR 50~ERL00203 ~ 
, D C _ _ CALL ...ADDRESS 5 1 ERL00204 

DC *&1 TABLE READ I OCC 52 ERL00205 

DC /CEOQ 53__ER.L_Q.Q2Q6 

*DISK DATA TABLE —-SEC TOR ERL00207 
DC 11 TABLE._WpRD_COUNT _54_.ERL0.0208 

DC SECTOR ADDRESS 55 ERL00209 
DC .0 RACK LABLE _ . 56 ERLQ02.1Q 

DC FIRST SEC PRO WK STO 57 ERL00211 
DC L ASTCr.l „SEC. PRO. WK._ STO 58„ERL 0.0 2.1.2 

DC MODIFICATION LEVEL 59 ERL00213 
DC. , F.I RST_...B A D_.C.YL. _AD.D_ j6.0_._ERL 0.2. 1.4 

DC SECOND BAD CYL ADDR 61 ERL00215 
. DC THIRD. BAD. CYL. ADDR 62_.ERL002 1.6.. 

DC NOT USED YET 63 ERL002 17 
DC NOT. .USED__YE I 6 4...E RL 0.0 2.1.8 

DC NOT USED YET 65 ERL00219 

...... I A 6 6 ....... E G U„ * , ._ _ E RL 0.0.2.2 Q 

FAE EOU TA66-TA5 ERL00221 
ORG EAE*D0RG5*D0R.G4*£0RG3*^^^ 

S XI CDRSP TEST FOR NO. OF DISKS TSK10620 
CEXXZ- LDX 1 CON _.. _TSK1. 1.21.0. 

XIO X2 SNIOC TSK11211 
LP XL CDRSP ST.0L.NO • OF. DR.VS ...T0_ CjQ.UN.T_ TSK 1.1 370 

A XI Dl TSK1 1380 
SIQ__.._ ..COUNT _. ISKl 139.0. 

LDX LI T ADDSGr 1 TSK1 1400 
___LQOP 9. ._ L D 1 _0 L D D E V IC E . ..T A B. ADDR TSK 1 1 .4. 1 

BSC L *&5«6- ZERO-BRANCH IF OFF LINE TSK1 1420 

. S T.0_ I _ __ _T.SK 1. 1 4 30. 

BYSTA LDX L2 SET XR2 TO DEVICE TAB ADD TSK1 1440 
B.S.I_ BSYTS _ TEST.. . I /O... AREA BUS.Y_. 1 _._TSK.l 1 4.5.Q 

MDX 1 1 INCREMENT TO NEXT DEV TAB TSK11460 
MDX L COUNT 4-1 DECREMENT.. COUNTER TSK.1. 1.4.7.0 

MDX L00P9 LOOP FOR NEXT DRIVE TSK11480 
„ LDX L...CON _ RESTORE ...XR1 - _TS.K.L1490 

BSC L CEXIT AREA NOT FOUND-NOT BUSY TSK 11500 

COUNT. DC _ ___ _.. TSK1 1.5 1.0. 

BSYTS DC TSK1 1520 
LP 2_FJ0CC ARE. J./P AREAS. THE .SAME ISKl 15.3.0. 

S 3 AREAD TSK1 1540 
BSC ! *&3 * Z NO ....... BRANCH ..TO ...TEST... NEXT. TSKi 1.5.50 

LD 2 IND1 YES- TEST FOR BUSY TSK 1 1 55 1 
BSC- -I CEXTZLt 2 BUSY-BRANCH. T0_ I NI_T£ST_ TSKI 1552. 



BSC I BSYTS RETURN ' TSKI 1553 
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"0~ 



I.N3_ 



MDX 

.__LPX: 
ORG 

_ MDX. 

1N4 LDX 

__,QRG. 

MDX 

J.N5 .LDX. 

ORG 

STO 

MDX 

S„. 

s 

LP 

STO 
DC 



GOON 

L2..TA3 _ 

*-363*D0RGl *D0RG2*D0RG3 

GOO N . . 

L2 TA4 



TSK15531 
TSK15532 
TSK15533 
TSK 15.534 



AST AR 



DC 
.P.C__ 
DC 
DC 
ORG 
DC_ 
DC 
DQ_ 
DC 
ORG 
DC 

DC 

DC 

pc.__ 

ORG 
PC... 
DC 
DC 
LDX 
.LDX 
LDX 
LDX 
MDX 
STO 
ORG 
LDX 
MDX 
STO 
ORG 
LDX 
MDX 
STO 



ORG 

JDKO LDX 
1DKOA LD 
STO 
A 

JLP.EL.ETE_ 
SKLLV LDX 



*r363.*DPRG 

GOON 

.._..L2_.TA5 

*~3&3*D0RG 

X3 KYLEV62. 

L2 -DT5&1 

X1..CDRSP 

XI CDRSP 

L3. TADDS&12. ._ 

L2 TADDS&6 

TADDSM 

/4000 
/.A700 

Zl Z66 

20 

*-4&4*D0RG 

_/4ooo_; 

/C700 

Z1Z&7 

24 

*-4&4*pO_RG 

/4000 
/CFOO 

Z1Z68 
25 

*-4&4*D0RG 

IN 3 

IN4 

I N5 

13 TADDS6 1 

„ ,12 TADDS&2 

12 TADDS63 

_ 12 TAD DS 6 4 

2 
X2 IND1 

*~4G4*D0RG 

12 TADDS65 

2 

X2 I.ND.l 

*-4&4*D0RG 

12 TADDS66 

2 

X2._ IND1„ 

*-4&4*DCRG 

12 _ORSUP .... 

L2 TADDS01 

L2 .TADDSM 

2 LOGDR-CON 
TSK 60750 

I 2 T ADDS& 1 



1.* D OR G 2*P0R G 3j* DOR.GA 



1 *D0RG2*D0RG3*D0RG4*D0RG5 



DETERMINE WHICH KEYBOARD 
T E S T__ FC »R .. L E G A L_ DR V_. CODE__ 
TEST FOR LEGAL DRV CODE 
GET PHY DEV TAB ADDR 



AND PUT IN LOGICAL TABLE 

D I SK 3" ~ 

SENSE IOCC - DRIVE 3 



1 *D0RG2*D0RG3 

DI SK 4 

SENSE IOCC - DRIVE 4 



1 *Q.ORG 2 *P0RG3*D ORG 4. 
DISK 5 



SENSE IOCC ~ DRIVE 5 



1 *D0RG2*D0RG3*D0RG4*D0RG5 



RESET DISK DEVICE TABLES 



1*D0RG2*D0RG3 



1 *D0RG2*D0RG3*D0RG4 



1 *D0RG2*D0RG3*D0RG4*D0RG5 
XR2#DR t VE COUNT 
GET DEV TABLE ADDRESS 
THAT DISK OFF-LINE 



TEST TO SEE 



TSK15535 

.JLSKL55.36- 
TSK15537 

.TSK 15538. 
TSK15539 

..T.SK25760.. 
TSK26060 

_ T.S.K3978.0 . 
TSK39840 
TSK 3 9880. 
TSK39890 

.TSK4404g_ 
TSK531 1 1 
TSK531 12 ju 
TSK531 13 
T.SK531 14. 
TSK531 15 
TSK531 16 
TSK531 17 

^TSK531 18 

~ TSK 5 3 119 

JTSK531 l.A 
TSK531 IB 
TSK531 1C 
TSK531 ID 

_TSK53 11 _E_ 
TSK531 IF 

JTSK54471. 
TSK54472 
TSK54 473 
TSK55330 

_TSK55520. 
TSK55560 
TSK55591 
TSK55592 
TSK55593 
TSK55594 

JSK55595_ 
TSK55596 
TSK55597. 
TSK55598 

...TSK55599 
TSK5559A 

XSK5559B.. 
TSK5559C 
TSK56280. 
TSK56290 
TSK56460 
TSK60590 

TSK61080 
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LDRCD 



LD 

A— 



JBFLG 
-188— 



* DELETE NPS22370 
JtOEAC-MDX I 7_.« 

* NOP 

. CDEAC-. LD 2 _CDC ON6 2. 

MDX CDOUT 



IF JOB FLAG IS ZERO SKIP NPS05230 
ADDRESS— OF- DEV ICE— TABLE- NPS221 10 



-NPS26820. 
NPS26830 
JNPS2684Q. 
NPS26900 



LDX 

DC 

DC 

DC 

DC. „ . 

DC 

_ : DC 

DC 

DC 

DC 

BS S.- 
BSC 

BSC 

I NO 10 LDX 
.LDX 



STX 

Jisl0..1.6_LD._ 
OR 

SXQ_ 



2 6 

/BO 00 

/COO.CL. 

/DOOO 

/BO0Q-. 

/COOO 

/DOOO.... 









345 

L IN010«-Z 

_! 1N01 Q«.E_. 

II 192 

.1.2. 139. 

2 *£>1 

.LJL ...*-.* 

LI WSOVF 



NUMBER_ 

DR. 3 

DR.4____ 

DR. 5 
DR. 3 

DR. 4 

DR • 5 

DR.3 
JDR..4 



OF DISK DRIVES 



DR. 5 

_..*THI S_ BSS MUST . BE. AT LEAST*. 
BR. IF NON— PROCESS 

BR.. I F.- NOT_ AN. ..INTERRUPT 

NO. OF DRIVES 



CL BO 7770 

CL~B0829T~" 
X L- B - 08.2 9,2. _ 

CLB0S293 

CLB 0837.1 ... 

CLB08372 
XLB08373__ 

CLB08441 
.CLB 08.4 4; 

CLB08443 
XLB21530. 

CLB231 10 
XLB23150 

CLB23280 
X.LS23290. 



CLB23291 

GET -DEV I CE ...TABLE PO INTER CLB2.32.92_ 

FLAG BIT%B0#1 □ • DRV .CD . %B 1 -B3n CLB23350 
L I. - WS.0 VF._.M AX. RE L ATI.V.E. . D.l SK^ADDRESS . CLB.23360. 



-EOUOO.. EOU 

LD L 

ST.0_.L-- 

SLA 

S L._. 

STO L 
LDDBL. LDD. .... I 

LDX I 1 

_m.qx_ i 



_.o 

189 
_PR TCI 

„.1.92 „_ 

PRTCL61 

. STGPK 

188 

_-l 



STX 

.LD.„ 
SLA 
STO 



LDX 

MDX. 

HMDRV LD 

DC 

DC 

.PRTCL__DC 

DC 



1 



I 1 
LI 



HMDRV61 

.J9.1 

12 

_SA 

191 

_1 

*_* 

1 88 _ 

5 

* «- * _ 

*-* 



INITIALIZE START OF TABLE 

_ O F_ADQR E S S E_S_O.E_ DEV I CE 

TABLES 

J NJ.T I AL.I ZE__DRJ_VE._COD.E__ 

NUMBER 



XL DO 27J . 

CLD03605 
JCLD.036.06_ 

CLD03607 
_CL DO -3.6.08. 

CLD03609 

CLD036.1 0. 

CLD05750 
.CLD05.752 

CLD05754 
._C.LD057_56. 

CLD05758 

CLD0575A 



SA DC 
JLjREMOVE .CLD1 
* REMOVE CLD1 

NXTS9 LDX 11 

STX 1 



5720„AND...C 
7140 THRU 

_188 

SETDR& 1 ' 



SET UP LOOP COUNTER CLD0575C 

CLD0575E 

PICK UP DEVICE TBL. ADD. CLD05760 

J5ijDDRE_SS__W.QRDJ^ C.L.D 1.44.6 0_ 

WORD COUNT " CLD 14470 

_ADDRE3S._W.0RDJ5-PJi^ CLD. i 44.8 L 

WORD COUNT CLD 14482 

CLD 14483 

CODE CLD 14760 



DRIVE 
LDJ573p„_ 
CLD 1 8330 

__X R JL* LA PP _ _Q PL 



LOG DRV TAB 



CLD1 71.4P_ 
CLD17150 
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SOURCE LANGUAGE CHANGE CARDS 



STX 

MDX 

_SXX_ 
LDX 

-MDX.... 



STX 

LDX_.. 

LDX 

JMEXCL LDX . 

_*_J...NJLXLAL 

..REDO A ..LD 

EOR 

BSC . 

MDX 

.MDX 

LD 

EOR _.. 
BSC 
.KDX_. 
NOP 

.BSC ...„. 



I 

_ X 
1 

_JL 
I 1 
_JL 
1 

LI 

2 

_...3. 



B0GDW6 1 
.NOTYTfclL 

-1 

.NQXYXfc5_ 

190 
X 

SETDR&5 

RDBUF617. 



-6 



CLD17160 
JCLD.17170. 
CLD 17180 

CU_XXL_.0_ 



XRl 
XR2 
XB3 



JPi3JNXS_XCL_C.QL_l.eL 

LOGICAL UNIT COUNTER 
J.S. COMP ARE„XAB...P.O I NT£R_ 



CLD17200 
JZLDAZZ.LCL 
CLD17220 
.CLD 1 7230 
CLD17240 
„CLD 1.7250 
CLD 17260 



TH.E...LOGJ. CAL DRJ V.EJ5 .„ERR_08.J^CL«__X0. 



_1 
L3 
L_ 
3 



JERCRD-. 



.E.Q.UQO 

NUMBR6-6 
SETDR , G~ 
1 

. RED OA 

1 EOUOO 

NUMBR&6— 

L BLNAK ♦ 6— 
I __RRX0.*J__ 



_BA.QC.D_ 



_CLD 17270. 
CLD17280 

LOAD, HOLLER LT.H..DR I VE „_CQDE. CLDX7.290 

COMPARE TO TABLE ENTRY CLD 17300 

BRANCH... QNL E.Q.UAI I.0„S_.T„D^ J ,__C.LD.l_73_l.a_ 

NOT EQUAL* STEP DOWN TABLE CLD 17320 

-NQ.Z _AT__E N D_.i2.F__X ABLE .« R EBE AT C L D 1X33 0„ 

END OF TABLE ♦ COMPARE BLANK CLD 1 7340 

CLD 1.7350 

EQUAL BRANCH TO TAKE OFF L CLD17360 

.N0_T_._V.ALXD_..C0DE-NQX._BLANK CLD1.73.7_>. 

GO TO ERROR 10 CLD17380 

_CLDA7.390 

CLD17400 
CLD 174 10 



_STjQRE_ SELECTED^ 



* 

.SET DR. 



* 

B.0GDW 



TEST 



LD__ 
BSC 
LD 

STO 

MDX 
MDX 

MDX 

_MDX_ 

NOP 
MDX . 

FOR 

Ton 



L2. 
L 

L3 



*-* 

ERCRD* 6- 



L2 
1 



*-*_ 
2 

*_ 3 
2 5 



ERROR IF NOT ON LINE 

FROM PHYSICAL UNIT TABLE 

ST OR E _ T 0_L .0 GJ CAL UNIT 

BUMP TO NEXT CARD COLUMN 

TEST. FOR LAST LOGICAL .UNIT 

LAST UNIT* GO TO CHECK DUPL 



NEXCL 

DUPLICATION IN 
PUNCHED IN" THE 



PROCESS NEXT COLUMN 



LOG I CAL 
CARD* 



DRIVE CONFGURAT- 



.CHARl 



LILJO 



LDX 


1 


5 




STX 




CQNFG. 




LDX 


12 


CONFG 




MDX— 


2 


- 1 „ „_ 




NOP 








LD_ 


LX 


_ - * 




BSC" 


L 


LILJO* 


& 


EOR 


L2 


*-* 




BSC 


L 


ERCRD ♦ 




MDX.. 


_.._2 


-1 




MDX 




NOTYT 




MDX 


_._L 


-1 




MDX 




CHAR 1 




MDX 




BNCRT 





SET COUNTER FOR OUTER LOOP 



SET COUNTER FOR INNER LOOP 



LOAD TESX_.W_0.RD-1 

IF ZERO, SKIP COMPARE 

COMPARE 

IF EQUAL* BRANCH TO ERROR 

BUMP COMPARE COUNTER 

BRANCH FOR NEXT COMPARE 
NO EQUAL, MOVE TO NEXT . 



CLD17420 

_CLDJ.743Q_ 
CLD17440 

„C.LDJ_7450_ 
CLD 1 7460 
CLD 1.7470. 
CLD1 7480 
CLD1.749CL 
CLD1 7500 

_CLP 1 75.1 0. 
CLD 17520 

XLPL7530_. 
CLD 1 7540 
CLD 1 7550 
CLD 1 7560 

p.LDl_7570 
CLD17580 
CLD17590 
CLD17600 
CLD 1.76 10 
CLD1761 1 

XLD1 7620. 
CLD1 7630 
CLD 17640 
CLD17650 
CLD 1 7660 
CLD 1 7670 

j:LD1768p_ 
CLD 17690 
CLD17700 



CLD17710 
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SOURCE LANGUAGE CHANGE CARDS 



PUT THIS DISK DRIVE OFF LINE 



BLNAK 



SRA 

JMDX__ 



16 

.BOGDW. 



ZERO THE ACCUMULATOR 



# 
* 



BNCRT 



# 

CONFG 

N.UMB.R 



LDX 
LDX 
LDX 

BSC 



DC 
_DC. 

DC 
.DC. 

DC 



I 1 
12 
13 



SVXRl. 
SVXR2 
SVXR3 
INTPT 



JgE ST ORE _I NDEX REGISTERS 



CLD1 7720 
XLD 1.7730.. 
CLD 17740 

XLDU7.7_5.0_. 
CLD 17760 

_CJLDJ.7^7_Q_. 

CLD 17780 
_CLDl'77?p_ 
CLD1 7800 
CLD17810 



RETURN 



DC 

DC 

DC._ 

STX L3 

LDX.. II 

REMOVE CLD23640 



*~* 

./20.00 

/1000 

/O800 

/0400 

y.0200 

/Ol 00 

y 00.00 

SVZR3C, 1 

.1.88 

THRU 



._Q_. 
1 

2. 
3 
„4 
5 



CLD1 7820 

CLD 17830 

CLD 1 7840 

CLD1_7850_ 

CLD1 7860 
.CL.PX7870 

CLD 1 7880 

XL.QX7890. 



CLD17900 

BLANK CLD 1.79 1.0. 

CLD23401 

_T0__L0G_. DEVL ._TAB__ J:LD_23_440_ 



LDX 

STX 



__LDX 13 



MDX 

DR0.V2 LP 

BSC 

, BS.I„_. 

LD 

A 

STO 

MDX 

MDX 

MDX 

LDX 



a. _. 

3 DRIVE 

-19J 

3 1 

1.0. 

Z 

SEAR.C 

DRIVE 
_2_ D_l 0.0 - MDX LQ .3 

DR I VE 



XR 1.. PQ I NTS 

CLD23840 

. JNXT_.JDRV.-X.ODJE -XO„.ZERCL 



XR3 IS LOOP MONITOR 

L P D E VICE.. TAB LE...A DDR ESS 

SKIP SEARCH IF ZERO 
NO T„. ZERO G0._. . .T _ S E A RCH 
NOT FOUND* INCREASE DR« CODE 



CLD. 2.36 40 

CLD23650 
„.CLD236.60..._ 

CLD23670 
._...CLD_2.3_680_._ 
CLD23690 

CLD23700 

CLD23710 
_CJJ__2_372_Q 



SVZR3 



. .1 _1_ 

3 -1 

DRQV2. 

L3 *-* 



I NCREASE _DEV I CE _L I ST . ADD.R • 
TEST FOR LAST LOGICAL DRV. 
NOT LAST, CONTINUE SEARCH 



CLD23730 
CLD23740. 
CLD23750 
.CLp2376p_ 
CLD24131 



LD 

_J_1DX_ 



LI ENDLZ6C0MMA 



STX 

JLDX. 
SRA 

STQ. 
LD 
SRA. 
STO 



XL 
1 

xa 



DLOG0_ 
*61 

_*-* 

4 

NPSCC. 
NPWST 

4 

EFFHM 



DCT091 10 
DC TO 9 12 0.. 
DCT09130 

XlCXQSU..4.0„ 
DCT09150 

XXT09160 
DCT09170 
DCT09180 
DCT09190 



_ LFD0414i_ 

LD 1 9 LFD04142 

S 2 . 7 „. CMP.._F_OR_ .# 3_ #.%DR ..3a._. LFP04.1.43 

BSC L LET3 « &- LFD04144 

LFD04 145 . 



LD 19 LFD04 146 

_S 2_a CMP_. FOR ...» 4 • %DR__.4o J_____ .LFD04147 

BSC L LET4«G- » LFD04148 J/^j 
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SOURCE LANGUAGE CHANGE CARDS 





* 


LD 


19 




» 


LFD04149 
LFD0414A 






S 


2 9 


CMP FOR 


•5 »%DR 5n 


LFD0414B 






BSC.'. 








LFD0414C 






MDX 


ST ART— 2 






LFD04271 




„ LET 3 LD 


C3 


DRIVE.. _3 




LFD04272 






STO 


DRV 






LFD04273 






MDX. 


START-2 






LFD04274 




LET4 


LD 

S.TO. . 


C4 

.DRV 


DRIVE 4 




LFD04275 
LFD04276 






MDX 


START— 2 






LFD04277 




LEX5_ 


_.LD 


C5 


DRIVE 5 




LFD04278 






STO 


DRV 






LFD04279 






S 


CI 






LFD04470 






BSC 


L LTDR2 « £r— 


DRIVE 2 


REQUESTED 


LFD04472 




* 










LFD04474 






S 


CI 






LFD04476 






BSC 


LTDR3« &- 


DRIVE 3 


REQUESTED 


LFD04478 




* 


S 


Cl 






LFD04480 
LFD04482 






BSC 


LTDR4 « 6- 


DRIVE 4 


REQUESTED 


LFD04484 




* 










LFD04486 



LTDR2 



LTDR3 



LTDR4 

DR3CD 
DR4CD 



DR5CD 

C3 

C5 



LD 

LD 

_MDX.. 
LD 

MDX 
LD 

,MDX_ 
DC 

DC 

DC 

..DC.. 
DC 
DC_ 
DC 
DC 



PR5CD 
JLET0&2. 
DR2CD 
.L.ETP&2 
DR3CP 
LETP&2 
DR4CD 
LET0&2 
'/3001 " 

/5001 

_3 

5 

„/F340_„ 
/F440 
/F540 



DRIVE 5 REGUESTED 



LFD04488 
LFD0448A 



LFD0451 1 
LFD04512 



LET SAD 
MI-SAD 
LET SAD 



.3 • 

• 4 . 

♦ 5 • 



DR 
DR 



LFD04513 
LFD04514 
LFD04515 

LFD 04516 

L FDO 46 ff 
LFD04612 



LFD04613 
L.FD04651. 
LFD04661 
JL.FD0794JL. 
LFD07942 
LFD07943 



A L DLOGO 

, STO *&l 

LDX 12 *-* 

_*REMOV E. S.C.T 8.20 Q_ 

DLOGO 

*61 

*-* 

JJADBZ&C. 
DLOGO 

*Cl _ _ . 

*-* UPDATED 

DLOGO 

*01 

: 

♦REMOVE SCT15410 AND SCTI5420 



me>x 


I 1 


STX 


1 


LDX 


12 


.LP. 


„L.l_ 


MDX 


I 1 


STX 


1 


LDX 


12 


A 


_.L ..... 


STO 




LDX 


...12. 



SCT08170 
SCT08180 



AT XEQ T I ME * ADDR OF INST SCT08190 



SCT09660 
SC JO 96 70 
SCT09680 
SC TO 982 0_ 
SCT09830 
SCT0984Q 
SCT09850 
.SCT15380. 
SCT 15390 
SCT15400 



'#1*407-1 



DC 

-DC- 
DC 



ONECN 
ONECN 
ONECN 



APPENDIX B- 



TSX MODIFICATIONS TO SUPPORT 
- SIX DISK DRIVES 
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SOURCE LANGUAGE CHANGE CARDS 



DEL06251 

DEL06252- 

DEL06253 



_GWSAD_LDX__.I3 DRNUM. 

MDX 13 DLOGO 
STX _ 3 *Grl .... 

LDX 13 *-* 



_XR3_ CON.TAI NS._DR_.XODE— 



DR. WRK. LVL._.ADDR. 



-DR.1064J3.Q. 
DP106440 
DP 106450. 
DP106470 



.._ LDX I 2 DLOGO 



_QWR.06.47Q 



SLT 

RTE 



1 

17. 



SRP04760 
SRP047.70 



LDX I N 

AP-XP.2. 

LDX LN 

APTP2 
* 

DKDEV 
DKLP_._ 
RPLDK 
BRLND. 



ST.ODK 
SA 



LD 

SLA 
STO 

_SLA 
S 

-0R.._ 
STO 
.STO 
STO 
LD .... 
STO 
STO 
A 

STO. 
LDX 

..D.C.._ 

LDX. 
DC 

LDX 

LD_„ 
LDX 

STO.. 
LDX 

LD 

DC 



L 

..L 
L 

.L 
L 
L 



1 

_LJ_ 
1 

LI. 
1 

LI. 



191 

12 _ . 

SA 

4 

192 

.LDX I N 

DKDEV 

RPLDK 

STODK-1 

1 93 ... 

DKLPOl 

STODKM 

APTP2 

RPLNDG.l 

*-* 

AP.T62 . 



1 . 

APT62 



LOAD MAXDRIVE CODE 
MOVE TO DRI VE.POSI T I ON 

STORE TO I/O AREA 

ZERO THE ..AC CUM 

LOAD NO • OF DRIVES 
„ _OR_ J N T O_ LD X __I N STRUCT . I ON. 

STORE TO PROGRAM 
STORE. TO. PROGRAM 

STORE TO PROGRAM 
S TORE DE V I CE. TABLE ..A D.D- 1 

TO PROGRAM 



BLANK LOAD INSTRUCTION 
START OF I/O AREA. Pl_US 2 

.BLANK L A D INSTRUCT.! P N 

START OF I/O AREA PLUS 2 



.*-*. 
*-* 

*-* 
*-* 



SAVE .USERS .2.31 0. ADDRESS. 

.RESTORE ..THE.. ENTRY 

XR1 ff NO* OF DRIVES 



DRIVE NUMBER 



EDP14941 

_EDP_1.4 9.42. 

EDP1 4943 

..ED P I 4944 

EDP 14945 

..EDP.l 4.946 

EDP1 4947 

_EDP.L49.48__. 
EDP1 4949 
EDP1494A 
EDP I 494B 

EDP 1 4 94 C 

EDP1 494D 

.EDP1 494E 

EDP1531 1 

.EDP 1.531 2 

EDP15313 

..EDP.1.53Sl.„;_. 
EDP15382 
EDPJ _5.383_.__ 
EDP0951 

EDP 09520 

EDP 10 140 

„E DP. 10.1 6.Q 

EDP1 0610 

EDP 1.0620 

EDP12080 



PSTVE 



_BSC 

MDX 
.LDX. 

MDX 

MDX _ 

LDX 
-SRA. . 

STO 

BSC 

MDX 



PSTVE 



1. .5 



GET AB6 1*11 
*&1 



1 2 



.11... _ 

AC 

E 

GET AC 



.IS.. ARE A... CO DE...L ES_S_X_A___J_6. 
YES 

NO ♦ XR 1 #5 IF .AREA ..CODE #25_ ._ 
SET UP FOR ERR CNTR I ND 



XR1#2 IF AREA CODE IS 9 
.PQS I.T I N_A RE A_ jCOD_E_J_I J_T 
SAVE HEX AREA CODE 

IS AREA CODE 9 OR 25 

YES 



_DSK0.1_C4Q_ 
DSK01042 
DSKO 10.43 
DSKO 1044 
DSKO 1 046 
DSKO 1048 

.DSKO. 1.0 50.. 
DSKO 1055 
DSKO 1 060 
DSKO 1 070 
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TSX MODIFICATIONS TO SUPPORT 

_ _ „ , SIX DISK DRIVES _ 

SOURCE LANGUAGE CHANGE CARDS 




(SET XR1 FOR DR CD# 1 0R4 



DSK01080 
DSK.0L0._90 
DSKOl 100 
DSKQLl 1Q. 
DSKO 1 1 15 



IS AREA CODE 8 OR 24 
...N0*SET_XR„1_F_QR„.DR„CD^0_QR3 
YES 

S A y E ...DR1V E__C.O.DE . „D.SK01.120. 

SET UP FOR ERR CNTR I ND DSKOl 125 

..LOAD... DRIVE.. CODE DSKO 1.1 30. 

SET UP DRIVE CODE FOR 2ND DSKO 11 35 

W OR D....PF... D I SK J C C DSKOl 1 AO 

GET HEX AREA CODE DSKOl 145 

..C0NVERT___I.0„. EBCD.l C DSKO 1.150.. 



AREA 

X.ODE. 



HFOFO 
PAREA&6 
*-* 

XNIR_ 
/FOFO 

.Jf.REMOVE . DSKO 1 730 ..THRU _ 
^DELETE DSK 02290 AND 

X.N.TR DC Q 

* 

STO PAREA.Gr9_. 

STO CNTR 

LD CNTR. 

*REM0VE DSK02830 THRU 
* RE MOVE. DSK 03200 THRU 



ST ORE. IN, PR ] NT „ AREA 

MODIFY XR1 FOR ERR CNTR 

_I N D _A.ND,„SXQRE LT 

EBCDIC MASK 

DSK 0.1.8 00 : 

DSK02300 

C QN T A.I N S_ C NT R_. _N0_£ OR _. 

HARDWARE ERROR 

C.QRELQAD„.NAM.E 

ZERO ERROR CNTR INDICATOR 



DSKO 1 155 
.DSKO 1.1.6.0. 

DSKO 1 160 
.DSKOl 17_0. 

DSKO 1 175 
JDSKO 1 1 80.. 

DSKO 1565 



DSKO 25.2.5. 
DSK02526 
.D.SK0359Q. 
DSK03780 
D.S.K0..3.050. 



ERR6 

ERR4 



8SI 

SSI 



D I SKN 

DI SKN 



DSK02850 AND 
DSK03220 . AND 
SEEK HOME 
SEEK HO'^E 



DSK02890 
DSK 03 260. 
ON DRIVE 

ON DRIVE 



TO 

TO 



DSK02860 

DSK03230 



DC 

DC... 

DC 

BSS 



4TH 2310 DISK STORAGE 
5TH... 23 10 D I SK ... STORAGE. 
6TH 2310 DISK STORAGE 
DUMMY LOCATIONS 



EUD0047 1 
EUDO 0.472 
EUD00473 
EUD00480 



LDX 


1 


28 




LENGTH OF 


ERR CNTR TABLE 


CEAO 1000 


LDX 




TOUT-l 




MESSAGE 


BUFFER 


CEAO 1010 


EBC 




• 2310 


20 


• 




CEA0201 1 


EBC 




.•_.?310_ 




• 




CEA020 12 


EBC 




• 2310 


25 


• 




CEA020 13 



ERCT equ 




./FEFO 


OUTPUT AREA .. 


..CEB00540 


LDX 


LI 


1 14 


TO BE PRINTED OUT 


CEB00670 


LDX 


1 


_6 


MAX NO OF UN 1JS THIS DEv 


_CE.B_0.L2.La 


LDX 


I 1 


193 




CEBO'l 250 


LDX 


I 2 


.187 




.CEBO 1.260 


LDX 


2 


6 




CEB01750 


LDX 


..LI 


BUFF 68 




CEB0.1760 


LDX 


1 1 


187 




CEBO 1 780 


LDX 


I 1 


193 




CEBO 1810 


LDX 


2 


7~ ~"~ . 


N0» OF LINES OF OUTPUT 


CEBO 1840 


s 




K6 




CEBO 2760 


s 




~K2 




CEB02780 
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TSX 1VD PI FI CATIONS TO SUPPORT 

SIX DISK DRIVES . 

SOURCE LANGUAGE CHANGE CARDS 



DC 




2 


DC 




6 - 


s 




K6 


LDX 


11 


.193 .... 


STX 


1 


*&2 


LDX. 


1 


6 


LD 


I 1 


•*-* 




_.L_. 


K6 


DC 




/l OOO 


DC 




/5000 



K2 DC 2 TEST IF 1053 CEB02920 

K 6 DC - . 6 - TEST IF 23 10 - CEBO 2960 - 

CEB03840 

CEBO 3951 

CEB03952 



... SET . .TO . MAX. ...NUMBER : CEBO. 3.960 

HSEEK LD II *-* TEST IF DRIVE ON LINE CEB03970 

CEB04 100 

DIV DC /1000 USED TO CALC NEXT DRIVE CEB04191 

SA DC /5000 CEB04220 





DC 




/3000 




SKA04000 






DC ... 




/4000 




SKA040 1 






DC 




/5000 




SKA04020 







.... _ A 


_ L ... 


188 


_ ADDRESS OF...DEV.I CE TABLE 


SKA16140 








*REM0VE SKA 16400 


- 


^ 







LDX 


I 1 


1 88 


LOAD ADDRESS OF 


TRLO 1 580 






STX 


1 


*& 1 


DRIVE ZERO 


TRLO 1 58 1 






.. ... LDX 


11 




DEV I CE TABLE 


TRLO 1 582 






LDX 


I 1 


188 


GET FILE PROTECT STATUS 


TDDO 1290 






... . STX 


1 


*&\ 




TDDO 1 29 1 




X) . 


LDX 


I 1 






TDDO 1292 






_. MDX. 


2 


-5 


BRANCH BACK TO ST1 IF 


ID_P.0.0810„._._. 






MDX 




ST 1 


DRIVE CODE ILLEGAL 


TDP00820 




— 


.... _ LDX 


11 


187 


GET LOGICAL DRIVE 


T DP 00 821. 






STX 


1 


*- 1 


DEVICE TABLE 


TDP00822 




: 


LD 


. L2 





ADDRESS 


TDP00830 . ._ 







LD 


L 


DCONM 




TDPO 1 630 




_.. 


LDX 


12 


188 


. LOAD ADDRESS OF 


TUP00480 







STX 


2 


*& 1 


DEVICE 


TUP00481 






.. LDX 


12 


*-* 


TABLE 


TUP00482 






LDX 


13 


188 


SAVE BAD CYLINDER 


TUP00840 






„..MDX. 


3 


.1 


„ ADDRESS 


.T.UE.0 084.1 






STX 


3 


*&1 


ON 


TUP00S42 






LDX 


.13 


_*— *. 


. . .THIS . ... 


__T.UP0.0843 






S 


L 


191 


A-ND BRANCH TO ERROR 


TDL01890 






LDX. 


. .11 


188. 




TDLO 1 .98.5. 






STX 


1 






TDLO 1986 






_ LD . 


L2 




BRANCH TO ERROR ROUTINE 


TDLO 1990 






AND 


L 


HOOFF 




TDL02340 






MESS3 EBC. 




... DRIVE 


CODES— HEX .0 ...1 2 .3. 4 5 


• T.WA.Q045.0 






S 


L 


191 


MUST BE 1 2 3 4 5 


TWA00850 






A 


L 


.187 


GET . D I SKN DEVICE TABLE 


ADD T.WA00 865 






LD 


XI 







TWA00890 
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~ TSXl&DIFICATIONS TO "SUPPORT " " " ^ 

SIX DISK DRIVES ■ 

SOURCE LANGUAGE CHANGE" CARLS " 
. ~ ! ' i> 



DC /1000 2310-3 BT 100731 

DC /JKlSLO- BXiDJD__3_2_ 

DC /1000 2310-4 BT100733 

.DC— /£ZO.Q. aUL0.O23.4_ 

DC /1000 2310-5 BT100735 

DC __/£EQQ . ___ BXl£)_rZ.36_ 



DC /1000 2310-3 BT200281 

_DCL ZAXOi) BT2£J3ma_ 

DC /1000 2310-4 BT200283 

_DC _ZC7.QQ . ; __J3X2JD.Q__fi4 

DC /1 000 2310-5 BT200285 

_D_L__ __^_CE__D. BT200286 



A L 188 * * MD 1 02590 



£RmOX£-M> I Q2800 



' • A L 188 ' * - * : , MDN00440 
* REMOVE MDN00970 



OS/360 FORTRAN REREAD 



A. Known Restrictions 

1. In its present form, REREAD did not work for a program which 
the E-level compiler suggested subdividing. We got around this 
by 

MAINLINE : CALL RR 
Etc. 

SUBPROGRAM: SUBROUTINE RR 
CALL REREAD 
RETURN 
. END 

This apparently let FORTRAN handle linkage conventions for a 
module small enough that use and nonrestore of register 8 by 
REREAD did not hurt us. 

2. We have not tried it (REREAD) with data sets organized as direct 
data sets. Author said it will not work. 

3. REREAD will not work with a variable for DSRN: 

READ (J, 3) list 
3 FORMAT (etc.) 

is not possible. 

4. As distributed, REREAD is for an E-level system. If your system 
includes G- or H-level, or is restricted to G- or H- level, state- 
ment 3 of the Assembly Language source code should be changed 

to 

EXTRN IHCFCOMH 

5. As distributed, REREAD uses DSRN 19 for REREADing. To choose 
another DSRN (£99) , change statement 44 of the Assembly Language 
listing (as distributed) to 

119 DC F'xx 1 

where xx is the DSRN you desire to use. Author says this number 
is independent of number of DSRN's chosen at SYSGEN time, and 
that a DD DUMMY card does not have to be included. 

B. Use 

1. It is necessary to issue the statement 
CALL REREAD 



once and only once for each FORTRAN program in which REREADing 
is to occur. This call must be executed before any REREADir? 
takes place. 



2. After B.l has occurred, REREADing is accomplished by 

READ (19, f) list 
where f is the FORMAT under which REREADing is to occur. 

3. Any number of 

READ (19, fO list-L 
READ (19, f 2 ) list 2 

• • • 

READ (19, f n ) list n 
can occur for the same buffer load. 

4. An application: User reads cards which occur randomly with . 
respect to type, but each card contains its type identification 
in the same field (say, Col. 56). Let DSRN = 1 stand for the 
system reader. Then 

READ (1, 11) J TYPE 
11 FORMAT (55X, II) 

GO TO (ai, a 2 , a n ) J TYPE 

a x READ (19, f x ) list x 

GO TO 

a 2 READ (19, f 2 ) list 2 
GO TO b 2 

• • • 

READ (19, f n ) list n 
GO TO bn 

will accomplish this. 

•Function 

CALL REREAD 

substitutes the address of ZZZ for the address of FJOCS in the 
FORTRAN I/O area. 

Each subsequent 

READ (n, f) list 

passes through ZZZ, where the pointers to buffers are saved and it 
is examined for DSRN = 19. If DSRN 4 19, then the control returns 
immediately to FORTRAN I/O for a physical read. If DSRN « 19, then 
the buffers are restored to their condition for the previous READ, 
physical reading is bypassed, and control is returned to FORTRAN 
I/O for FORMAT ting only. 
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//REREAD JOB 
//STEP! EXEC 



MSGLEVEL=1 
ASMFC.LtPARH, 



LKEO=(MAP,LET,NCAL,DC) 



DO 
DO 
OD 
00 



//CO.VP 

//SYSLIB 
V/SYSUT1 

//SYSUT3 

/■/SYS0T2 
V/SYSPKINT 

//SYSPUNCH 

// 

//CCMP.SYSIN DO 
l£F236l ALLOC* FOR 
SYSLIB 
SYSUT1 
SYSUT 3 
SYSUT2 
SYSPUNCH 
SYSIN 



EXEC PGM=IEUASM 

DO DSNAME=SYS1.MACL ID,DISP=OLD 
00 UNir=OISK,SPACE= ( 1700, (AGO, 50) ), D ISP= < NEW, PASS ) 



( 1700,(400,50) ) 



UNI T = DISK,SPACt= ( 1700, (400, SO) ) 
UNlT=(UlSK,SEP=(SYSUTi,SYSUT3) ) .SPACE 
SYSOUT-A 

DSNAME=tL0A0SET,UNIT=DISK,SPACE=(400, ( 50,10) ) , 
DISP=(MOD,PASS),DCB=(,DLKSiZE=400> 
DATA 

CGMP STEP! 



IEF237I 
IFF237I 
IEF237I 
I.EF237I 
IFF237I 
IEF237I 



REKFAD 
ON 190 
190 
190 
191 
191 
OOC 



O000CO10 
00000020 
00000030 
00000040 
00000050 
00000060 
X00000070 

oooooobo 



ON 
ON 
ON 
ON 
ON 




EXTERNAL SYMBOL DICTIONARY 



"SYMBOL "TYPE * I D ADOR LENGTH LD TO 



PC 01 000000 000002 
REREAD LD 000000 01 

IHCFCOME ER 02 

ihcf icsh ""pr"' 03 " : " ' 
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ICC OBJECT CODE 



OOOOOO 



ADDRl ADDR2 STMT SOURCE STATEMENT 



r\ rt /"\ r\ rt rt 


tone 










rt rt rt rt rt -rt 

OOOOOO 












A A A A A *> 

OOOOOZ 


c n t A 

bO 1 


e> a r o 






rt rt rt r o 

000C8 


n a m n / 
000006 


SO 10 


O A 1 A 

80 ( 






A A A "7 A 
000 / 


OUOOOA 


58F0 


8074 


, . t . 




00074 


a A A A A c 
u b 


92 50 


c A y A 
r 04 A 




rt rt rt v a 
OUO*» A 




Ol/OU I z 


HiUr 


004 A 






0004 A 


f \ rt rt \ i 

OOOO 1 6 


92 50 


F04 A 




0004 A 




rt rt rt rt 1 a 

oo no l a 


58 1 


80C0 






000C8 


0000 I b 


O irl- 










f \ A r\ A "5 A 
OUUOZ 














OOOOOO 


a a / n 
V04 r 


1 A C O 






A A A f O 
OUO / O 


00U0Z4 


1 O U I 










rt rt rt rt rt 

oooozo 












rt f \ rt rt *i * 

OOOOZo 


1 O A A 
1840 










r\ n n A T r 


UvUl 


A A A A ' 


- o rt n /v 


-rt A rt rt rt 


A A A A A ~ ~ 


00002E 


4 780 


B0 1C 






000 3C 


rt rt rt i "» 

0000 32 


5010 


80 AO 






oooco 


000036 


90 4 F 


D058 






000 78 


00003A 


7 F I 










00003C 


D50 3 


E000 


B0A4 


rt rt rt rt rt 

00000 


000C4 


rt rt rt rt / t 

000042 


4 / oO 


B0 3C 






0005C 


rt i \ rt rt / / 

000046 


18ZC 










#\ rt rt rt / r» 

00 004 


5810 


BOAO 






OOOCO 


rt / \ rt rt t /* 

C00Q4C 


0501 










rt rt rt rt i c 

00004 E 


O0F0 










r\ r\ r\ t\ a n 


5020 


B0A8 






nnnr ft 
uuuuo 


nnftn ca 
OUUU5't 


5030 


DOAC 






■ nnnr r 


a t \ (\t\ u 


47F0 


B044 






UuUOt 


UUUU jt 


5820 


BOAO 






nnnr n — ' 


000060 


5830 


OOAC 






000CC' 


000064 


4U4 


0002 






00002 


000068 


984 F 


B058 






00078 


00006C 


07F1 










00006E 


0000 










000070 


00000020 








0000 74 


oooooooo 








000070 


oooooooooooooooo - 




OO00C0 


oooooooo 








00G0C4 


00000013 " 








OOOOCO 












0000CC 












000000 


00F0 












40 ADZZZ 

41 A01BC0M 

42 SAVE 

43 ADFIOCS 

44 I 19 

45 SV1 

46 SV2 

47 H00F0 
43 





REREAO 

IHCFCOME 

IHCFIOSH 
8,15 
RE RE AO 1 8 
i.SVl 
1 , ADZZZ 

15,AniBC0M 

74( 15) ,X'50* 

0. 74(15) 
74( 15) ,X«58« 

I, SV1 
15, 14 

■ *,l 

4,15, SAVE 
1 

II, 1 

zzz,u 

4,0 

012,4) ,H00F0~ 
8,CHK19 

1, ADFIOCS— 
4,15, SAVE 

15,1 

0(4, 14) , I 19 

' 8, BYPASS 

2,14 

~ 1, ADFIOCS 

0, 1 

X« 00F0« 

2,SVl 

* 3, SV2 

15, LEAVE 

2,SV1 

3,SV2 

1,2(4) 

4, 15, SAVE 
15,1 
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061967WN 
061967HN 
061967WN 
061967WN 
061967WN 
061967WN 
061967WN 
061967WN 
061967WN 
061967WN 
061967WN 
061967WN 
061967WN 
061967WN 
061967WN 
061967WN 
061967WN 
061967WN 
061967WN 
061967WN 
061967WN 



DC 

OC 

DC 

OC 

DC ~ 

DS 

DS 

DC 

END 



Mill) 

A( IHCFCOME) 
lOF'O* - 
A( IHCFIOSH) 
F«19« ■ 
F 

F 

X'OOFO 1 



061967WN 
061967WN 
061967WN 

061967WN 
061967WN 
061967WN 
061967WN 
061967WN 
061967WN 
061967WN 
061967WN 
061967WN 
061967WN 
061967WN 
061967WN 
061967WN 

061967WN 
061967WN 
061967WN 
061967WN 

061967WN 
061967WN 
061967WN 
061967WN 



I i 



! O 
GOO Vi 



o o o 



o o o 
o o o 



> 
o 



o c o 


> 


o o o 


o 


o o o 


D 


ooo 




O -J 


m 


o o 


</> 







■ jo 
i m 
r~ 
O 

; O 

, > 

. — < 

:0 
;z 

; O 

! ^ 



10 

I 



o 
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CROSS-REFERENCE 



SYM80L 


LEN 


VALUE 


DEFN 


REFERENCES 


AOF IOCS 


00004 


OOOOCO 


0043 


0023 


0029 
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IEF285I _ SYSl.MACLIB „_________ __ KEPT 

ItF285l"" VOL SFR NOS- OQ0017. " " 
1EF285I AAAAAAAA. AAAAAAAA. AA AAA AAA .AAAAAAAA • 00000042 PASSED 
ICF285I VOL SER NOS= 000017. 

IGF28*iI AAAAAAAA. AAAAAAAA. AAAAAAAA. AAAAAAAA. 00000043 DELETED 
I t-I F 2 8 5> I VOL SFR NOS= 000017. 

IEF280I AAAAAAAA. AAAAAAAA. AAAAAAAA. AAAAAAAA. 00000044 DELETED 
I6F285I VOL SFR NOS= 000011. 

IEF285I SYSOUT - SYSOUT 

IEF28M VOL SER NOS = 

IEF285I LOADSET. REREAD PASSED 
IFF285I VOL SER NOS= 000011. 

// LKED EXEC PGM=IFWL,PARM=(MAP,LFT,NCAL,DC),C0ND=(5,LT,C0MP) 
//SYSLIN DO DSNAMF=&LOADSET,DISH= (OLD, DELETE), UNIT=DISK 
// 00 DONAME=SYS I N 

//SYSUTi 00 DSNAME =* . COMP. SYSU T 1 » D ! SP= ( OLD, DELETE ) 
//LKF.D. SYSLMOD 00 DSNAME=S YS 1 . FOR TL I 8 ( REREAD ) , D I SP=OLD 
//SYSLMOD OD DSNAME=T ES T. LOAD, D I SP=OLD 
//SYSPRlNT 00 SYSOUT=A 
// 

IEF236I ALLOC. FOR REREAD LKED STEP 1 

IEF237I SYSLIN CN 191 

16F237I SYSUTi ON 190 

!GF237t SYSLMOD ON 192 



On 



00000090 
00000100 
00000110 
00000120 

00000130 
00000140 



E-LFVEL LINKAGE EOITOR OPTIONS SPECIFIEO MAP.LET.NCAL.DC 

ICW0461 IHCFCOMF " " 

IEW0A6L IHCFIOSH 

****REREAD DOES NOT EXIST BUT HAS BEEN ADOEO TO DATA SET " " 
DIAGNOSTIC MESSAGE DIRECTORY 

I EW0461 WARNING - SYMBOL PRINTED IS AN UNRESOLVED EXTERNAL REFERENCE, NCAL WAS SPECIFIED. 



Q 



- 1 



MODULE MAP 



CONTROL SECTION 

NAME ORIGIN LENGTH 
^PRIVATE " 00 : D2 



ENTRY " ' ""' ."" " " ' 

NAME LOCATION NAME ""LOCATION ~ NAME LOCATION NAME LOCATION 



REREAD 



00 



ENTRY ADORESS 
TOTAL LENGTH 



00 
D2 



IEF285I LOACSET. REREAD OELETED 

IEF285I " ••VOL SER NOS= OOOOll." * 

IEF285I AAAAAAAA. AAAAAAAA. AAAAAAAA.AAAAAAAA. 00000042 DELETED 

IEF205I VGL SER NOS= 000017. " " ~ ' 

IEF285! SYS1.F0RTLIB KEPT 

IEF28SI VOL SER NOS= 000005. " ' """ 

IFF28SI SYSCOT SYSOUT 

I EF285 1 VGL SER NOS= . 





// TREREAD JOB MSGLFVEL=i 

//STEPl EXEC FORTECLG " "- " ' ■— " 

//COMP EXEC PGK= I E JF AAAO 

//SYSPRINT *DD SYSOUT=A - 

//SYSUT1 DO ONIT=OISK,SPACE=( 1024, (200, 10 ) ) , DI SP= ( NEW , PASS ) 
//SYSUT2 DD UNI T=DISK, SPACF= { IRK, ( 30, 10) } 

//SYSLIN DO DSNAME=£L0AD,DISP=(MO0,PASS),UNIT=DISK, SPACE* ( TRK,< 30,10) ) 

V/COMP.SYSIN DO DATA — ~" 

I EF236 1 ALLOC- FOR T REREAD COMP STEP1 

IEF237I SYSUTl ON 190 " - 

IEF23M SYSUT2 ON 192 
IEF237I SYSLIN ON 191 
IEF237I SYSIN ON OOC 



00000010 
00000020 
00000030 
00000040 
00000050 




On 



IEJ001I COMPILER OPTIONS IN EFFECT : SOURCE, MAP , LOAD , AD JUST, PRFRM , S I ZE=45056 , LI NELNG=132 
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C 061967 



IBM OS/360 BASIC FORTRAN IV (E) COMPILATION 



S • 0001 




DIMENSION A (20) 


S.0002 




CALL REREAD 


' ' C AAA'.* 

S> . 000 3 




,ir i a # c % \ A — » """""" " ' " 

Kb AD (5,1) A 


S • 0004 


*> 

2 


rUKMA I i * f t } 


C A A A C ' " 


I 


FORMAT (20A4) 






UlJ 3 1=1,10 


S.0007 


3 


WRITE (6,2) A 


S.000B 


10 


FORMAT ( 3F6.2, 14 ) 


S.0009 




READ ( 19, 10) X, Y, Z, J 


s.ooio' 




DO 5 1 = 1, 10 


S.001 1 




WRITE (6,7) X,Y,Z,J 


S.0012 


7 


FORMAT (• ••3F12.2 V U0) 


S.0013 




STUP 


S.0014 




END 
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061967WN 
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NAME 

A' 
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TAG 



REL ADR 

000154 
0001 BO 



STORAGE_ MAP 
NAME TAG 
I 



VARIABLES (TAGS: C*COMMONt E*EQU I VALENCE } 



REL ADR_ 

0001A4 
0001B4 ™ 



NAME_ 
X 



TAG 



REL ADR 
0001A8 



NAME_ 
Y 



NAME 
REREAD 

NAME 
NAME 

:occm# 

statement number 

00002 
00005 



REL ADR NAME 
0001B8 



REL ADR 

REL ADR 

000 1FC 

REL ADR 

0001C8 
0002B8 



NAME 



NAME 



E X T E R N A L R E F E R E NC E S 
REL ADR " NAME ~~ 

CONSTANTS ~ 
REL AOR " NAME 



REL ADR 



NAME" 



DATES 67.302 




TAG 



REL ADR 
0001AC 



REL AOR 



REL ADR 



NAME 



REL AOR 



IMPLIED EXTERNAL REFERENCES^ 
REL AOR NAME 



REL AOR NAME REL AOR 



STATEMENT NUMBER 



00001 
00007 



REL ADR 

000104 
0001E8 



STATEMENT_NUMBER 
00003 



R E L A D R STAT EMENT NUMBE R R E L ADR 

000248 00010 00010C 



SIZE OF COMMON 000000 PROGRAM 000782 
END OF COMPILATION MAIN 



IEF285I SYSOUT SYSOUT 

IEF285I -• VOL SER NOS= . " " ~ 

IGF28 r >I AAAAAA AA. A AAAAAAA. AAAAAAAA. A AAAAAAA .00000049 PASSED 
IEF2851 VOL SER NOS = 000017. 

IEF285I AAAAAAAA. AAAAAAAA. AAAAAAAA.AAAAAAAA. 00000050 DELETED 
IEF285I VOL SER NOS= 000005. 

ICF2U5I LOADi r RERE AO PASSED 

IFF28^>I , VOL SER NOS= OOOOU. . - 

// LKE EXFC PGM=IEWLtPARM-(MAP»LETfLIST»DC ) t CONO* { 5 , LT .GQMP ) 
//SYSLIB DO DSNAMC=SYS1.F0RTLIB,DISP=0LD 
//SYSUF1 DO DSNANE=*.C0MP.SYSUT1,DISP= (OLD, DELETE) 
//SYSPRINT DO SYSOUT=A 

//SYSLIN 00 DSNAME=£LOAC,DISP= (OLD, DELETE) 

// DO DCNAKE = SYS I N ~ 

// SYSLMOD DD DSNAME = SCO < MA I N ) , I SP= < NE W, PASS ) , UN I T=D I SK , 
// SPACE=( 3072, (20, 10, i) ) 

IEF236I ALLOC. FOR TRCREAD LKED STEP1 

ICF237I . SYSLIB ON 192 

ILF237I SYSUT1 ON 190 

IFF237I SYSLIN ' ON 191 " 

IEF23/1 SYSLMOD ON 190 
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00000080 
00000090 
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" 00000110 
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_ E-LEVEL LINKAGE EDITOR OPTIONS SPECIFIED MAP,LET,LIST,DC 
V**>MA IN *'""■' DOES NOT EXIST BUT HAS BEEN ADDED TO DATA SET" 




CONTROL SECTION 



NAME 


ORIGIN 


LENGTH 


MAIN 


00 


30E 


~S PRIVATE *" 


310 


02 


IHCFCOME* 


3E8 


"~ 1464 


~ IHCFIOSH* 


1850 


CF2 


"IHCUATBL*" 


"2548 


138 



MODULE" MAP" 



ENTRY 
NAME 



LOCATION 



REREAD 
IBCOM// 
FIOCS# 



310 
3E8 
1850 



NAME 



LOCATION 



NAME 



LOCATION 



NAME 



LOCATION 



F0I0CS# 



9F4 



ENTRY ADDRESS 
TOTAL LENGTH 



00 

2680 



IEF285I 
IFF285I 
ILF285I 
IHF285I 
IFF285I 
IEF285I 
IFF285I 
IEF285I 
IEF285I 
ILF285I 



SYSl.FORTLIB KEPT 

VOL SFR NOS=- 000005. ~ ' 

AAAAAAAA. A A A A A AAA . AAAAAAAA. AAAAAAAA. 00000049 OELETEO 
VOL SFR NOS= 000017. -» 



SYSOUT 

VOL SFR NOS= 
LOAD.TRFREAD 
VOL SFR NOS = 
CO. T REREAD 
VOL SER NOS = 



SYSOUT 



000011. 



DELETED 



PASSED 



0000L7. 

//GO EXEC PGM=*. LKED. SYSLMOD t COND= ( (5»LT»C0MP)» (5iLT t LKED) ) 

//FT01F001 DD DDNAME=SYS IN 
//Fr02F00L DD UNIT = PUNCH 

//FT03F001 DD SYSOUT=A " _ " 

//CC.FT06F001 00 SYSOUT=A 
//GC.FT19F001 DO DUMMY 
//G0.FT05F0O1 DD OA f A 

IGF236I ALLOC. FOR TREREAD GO STEPl " " - 

IEF237I PGV=*.OD ON 190 

TFF237I FT02F001 CN OOA 

IEF237I F105FC01 ON OOC 
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BCR 


15, 1 



LOAD 
LOAD 



as 



r<£>m 



r eA . (m^A er \ \ 3 



WITH 
WITH 



AODRESS 
ADDRESS 



OF 
OF 



III 

IJTACOM 



36 


ADZZZ 


DC 


bXLLlu 


■■■ - r 


37 


ADIBCOM 


DC 


A%IJTACOMo 




38 


SAVE 


DC 


18Fo)0a 




39 


ADF IOCS 


OC 


ASIJTFIOSa 




40 


199 


DC v 


Faioa 




41 


SVl 


DS 


F 




42 


SV2 


OS 


f 




43 


HOOFO • 


DC 


xaooFOOoooa 




44 




END 





t — »- 



SESSION REPORT 



Session No. ^ , / f~~ 

Session Titles // ?Q / */Zo T*=>~c-- 



Chairman : P A u _ jp /) > P k A L r / *w» > c 



Speaker J>,z / yf / u J"^ /^ / * j 



Topic s % //.. ? C fs? //u-n^^ a u u2l ± /f /O \ >/i/rtr " 



Speaker ; j£Jt B e ij 1 /~ O ) 



Topic ; // Xxl JZL£*LJ£ K cu -r < < L £ L jL * , U * ■ 1- 



Summary ; Cz±2^L Jju^y yL ^ ^ ^fy-— ^ ^ ^ / 



Speaker 
Topic : 



Summary t_ 



NO. OF ATTENDEES ; ^ZU^c 



OVERLAPPED PRINTING FOR IBM llJO COMMERCIAL 
APPLICATIONS USING FORTRAN WRITE STATEMENT " 



B. J. SWAIN 



THE SHAWINIGAN -ENGINEERING COMPANY LIMITED 
Box 3010 Station B, Montreal, Canada. 

~ ' , DECEMBER I967 



SO 6 



I 

i \ 



TABLE OF CONTENTS 



.ABSTRACT 
DISCLAIMER 



Page 

i 
ii 



TEXT 

I. Use of Fortran for Commercial Applications on the 
IBM 1130 - 

II. Programming Philosophy Using Commercial 
. Subroutine Packages 

III. Difficulties Presented by the Use of Commercial 
Subroutine Packages 

IV. Use of Fortran WRITE Statement for Output in 
Commercial Reports 

Definition of Alphabetic Literals Using Fortran 
READ Statement " 

V. Performance of the Subroutine 



APPENDIX I 



Fortran Output Routine, with Overlap 
Users "Guide 

WRITE 

READ . " 



12 
12 



TABLE OF "CONTENTS cont'd 



Page 

APPENDIX II "• 

Loading the Overlapped Fortran Output. Routine l6 

APPENDIX -III 

Source Listings 17 



O. 



ABSTRACT "- 

A method is described for incorporating overlapped printing" 
into IBM 11^0 Commercial FORTRAN programs. Communication 
to the subprogram which performs a printing operation is 
achieved through the FORTRAN VRrtE statement rather than 
through the CALL statement . The advantage of this method is 
that limited use can he made of the formatting ability of the 
FORTRAN language. Headings can readily be incorporated, and 
the layout of the printed page specifically by use of- FORMAT 
statements. 



ii- 



DISCIAIMER - 




Although each program has been -tested by its contributor, no 
'warranty, .express or implied, is made by the contributor or . "" " 
COMMON USERS Group, -.as to the accuracy and functioning of the 
program and related program material, nor shall the fact of 
distribution constitute any such warranty, and no responsibility 
is assumed by the contributor or" COMMON USERS Group, in connection 
therewith. 





OVERLAPPED PRINTING. FOR IBM 11^0 COMMERCIAL 
APPLICATIONS USING FORTRAN WRITE STATEMENT 



I. Use of Fortran for Commercial Applications on the IBM 11^0 « 
Since the IBM 11^0 was conceived as a computer to be used for 
the solution of moderate sized engineering and scientific problems, 
Fortran is the only compiler supported on the system. At many 
installations, it is necessary to use the computer, not only 
in this prime role, but also in the preparation of commercial 
reports, such as payrolls, labor distribution, and time control. 
In order to permit the use of Fortran for these applications, 
a number of subroutine packages have been developed. IBM's 
Commercial Subroutine Package, Version II, is an example. Others 
are the contributed program packages COMET and IDEAL. The 
purpose of these subroutine packages is to overcome the problems 
which would otherwise be presented in handling commercial appli- 
cations in Fortran. Principally these are the following: 

1) Moving character strings. 

2) Use of floating .dollar signs, check protection, etc. 
• 3) Elimination of round-off in crossfooting totals 

k) Zone recognition 

5) Stacker Selection . ~ 

6) Overlapped input/output for increasing processing 
speed. 



Use of Fortran - for Commercial Applications on the IBM 1130 cont'd 




The first five items in the list above exist .on account of the 
fact that Fortran is not intended as a commercial data processing 
language. The sixth -item occurs on account of the fact that the 
Fortran compiler for the IBM 13-3-0 has been designed to conserve - 



for use with Fortran -use the same_area in core as a buffer area to 
contain the image of a card being read or a line being printed. ., It 
is therefore not possible to overlap these operations, although the 
interrupt hardware provided on the system would otherwise permit 
this to be done. In the design of the IBM 1130 Commercial Subroutine 
Package, it has been recognized that for commercial applications, 
processing speed assumes a greater importance. Overlap of inp.it/output 
operations his therefore been achieved at the expense of the additional/^ 
core required for multiple buffers, and for the more complicated 
-subroutines -required to service the interrupts. 

II. Programming Philosophy Using Commercial Subroutine Packa ges 
The programming philosophy usually employed when commercial sub- 
routine packages are" used is as follows: 



1) Input data on cards- is read and stored as a -card 
Image, in EBCDIC form. A SUBROUTINE subprogram 
is used for this purpose. 

2) Tests are made to determine the type of card 
which has been read. 



core space as much as possible. The normal input/output. subroutines 
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3) Data is extracted from the card image, and stored 
for subsequent calculations* If it is to be used 
in arithmetic operations* numerical data is 
converted to a code which permits these operations 
to" be performed. 

k) At the conclusion of -the necessary calculations, 
an image is built up of the output line to be 
printed, in the report. Numeric information is 
reconverted to EBCDIC code for inclusion in this 
output line image. 



5) The output line is printed, using a SUBROUTINE- 
subprogram. - . - 

The use of this philosophy imposes virtually no restriction on 
the manner of presentation of data in the input file, or on the 
appearance of the final report. The subprograms for card 
reading and printing permit overlap of these operations, with 
each other. Conversion .from card code to -EBCDIC is also over- 
lapped with card reading. 

III. _ Difficulties Presented by the Use of Commercial Subroutine 
Pack a ges. 

Although the use of commercial subroutine packages in the manner 

described above overcomes the shortcomings of Fortran for commercial 




Difficulties P resen ted by t he Use of C ommercial Subroutine Packages cont*d 



applications, a- number of additional difficulties -are introduced. 
Principally these are the following: 

1) The introduction of "headings into the output 
report. . . 

2) Loss of tracing capability. IBM 1150 Fortran 
has been provided -with a very useful trace : 
feature. This cannot be used when the overlapped 
input/output subroutines of the Commercial 
Subroutine Package are loaded, as it is not 
possible to include the Fortran input/output 
subroutines' in the same core load. The Fortran 
input /output subroutines are required for the" 
use of the trace feature. 

3) A considerable amount of manipulation is often 
required to build an image of a line of the output 
report. This tends to make the coding of programs 
longer and" more prone to errors . 

h) The introduction of masks for editing. The use 
of Commercial Subroutine Package EDIT subroutine 
requires that non-numeric information to be mixed 
into a numeric field (such as $ . etc) be intro- 
duced in the form of a mask, which is- subsequently 



Difficulties Presented _by the Use of Co mmercial Subroutine Packages cont 1 d 

applications, a number of additional difficulties are introduced. 
Principally these are the following:. 

1) The introduction of headings into the output 
report. 

2) lLoss of tracing capability. IBM ll'j>0~ Fortran 

has been providccL with a very useful trace 
feature. This cannot be used v;hen the overlapped 
input/output subroutines of the Commercial 
Subroutine Package are loaded, as it is not 
possible to include the Fortran input/output 
subroutines' in the same core load. The Fortran 
input/output subroutines are required for the 
use. of the trace feature. 

3) A considerable amount of manipulation is often - ~~ 
required to build an image of a line of th-e output 

report. This tends to make the coding of programs 
-longer and more prone to errors. 
h) The introduction of masks for editing. The use 
of Commercial Subroutine Packa,ge EDIT subroutine 
requires that non- numeric" information- to be mixed 
into a numeric field (such as $ . etc) be intro- 
duced in the form of a mask, which is subsequently 



S/S 
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Difficulties Presented by t he Use of Commercial Su broutine Packages cont ' S 



destroyed by the inclusion of the numeric information. 
In view of the fact" that alphabetic literals cannot 
be directly defined in the IBM 11^0. Fortran- 
compiler, this operation is clumsy (Note - Version II" 
Of the IBM 1130 Fortran compiler includes "the DATA 
statement which overcomes this difficulty) . 



U s e of Fort ran WRITE State ment for Outp u t in Commerc ial Reports. 



Canada, an IBM 1130 computer was installed in January 19°7j 
primarily to perform engineering calculations. However, it was 
desired to use the machine for processing the commercial reports 



which would be required for the administration of the Company. 
A study was made. of the available software for commercial pro- 
cessing, and as a result a set of subroutines written, which 
combined the best features of the IBM 1130 Commercial Subroutine 
Package, COMET,- and IDEAL. 

In recognition of the difficulties which would be presented by 
the use of SUBROUTINE subprograms for printing, after the manner of 
the IBM Commercial Subroutine Package, it was decided to adopt a 
different approach. A new subroutine SFI0 (the subroutine which 
handles in Fortran the input/output functions) was written in 
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Use of Fortran WRITE stat ement for Output in Commercial Reports cont ' d 

ll^O .assembler language, having more limited capabilities than 
the .version supplied'as part of the system, but taking advantages 
of the overlap feature of the hardware. The advantages of this 
procedure over the use of the Commercial Subroutine Package 
subprograms are the following : . 

1) - Headings may be introduced by the use of a FORMAT - 

"statement, as is done in normal processing using 
Fortran. 

2) Tracing can be employed. 

3) The amount of manipulation required to format 

an output line is reduced, as the FORMAT statement 
may be used for this purpose. 
• It was not considered necessary to incorporate air the features 
vhich are supported" by the normal SFI0 subroutine as supplied 
"in the system. Indeed to have done so would have resulted in 
a subroutine occupying a large core space, a considerable portion 
of which would have been wasted, on features which would be rarely - 
used in the commercial area. The following restrictions were 
therefore introduced: - 

1) Only integer variables and arrays may he -included 
in the output list. - 

2) *ONEJ. WORD -INTEGERS option must be used. 



^5 
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Use of Fortran WRITE Statement for Ou tp ut in Commercial Reports cont 1 d 

3) Card reading is not supported, and all writing 
is done on the 1132 printer, regardless of the- 
device code appearing in the WRITE statement. 
Card, typewriter and console input /output are 
- handled by SUBROUTINE subprograms as in the IBM 
Commercjal Subroutine Package. . - - 

k) Oaly the following format field specifications 
are recognized: 

A for alphameric information. The only - 

field widths recognized are Al and A2 _• " ' 
Anything else is interpreted as Al. A 

I for integer variables 

X for spaces 

H " for printing alphabetic information. The 

- form using quotes may also be used. 

5) The group repeat, e.g. 2(lHl,12A2), is" hot recognized. 

6) Carriage control characters are restricted to 

the following : ■ _ ■ 

Blank Print on next line- " ' " ■ - ~ 
-Zero Skip one line before printing 
1- 6 Skip to channels 1 to 6 -~ 
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Use of Fortran W RITE Statement for Out put in Commerci al Reports cont' 

None of these restrictions prevent the use of the system in 
association with Commercial" Subroutine Package, COMET or IDEAL. 
An attempt to print a real variable will result in the output 
field being filled with asterisks. This restricts. the use of 
tracing to integer variables only, real variables appearing as 
a line of asterisks. -It is our experience that this is not a 
serious restriction, as it is the values of integer variables 
which determine the logic flow of a program. If it is necessary 
to determine the value of a real variable for tracing purposes, 
then this can be done by converting it to EBCDIC, for display 
using a VJRITE statement temporarily inserted in the program. 

Definition of Al phabetic Literals Us in g Fortran READ Statement 
In order to permit the definition of alphabetic literal character 
strings, a feature .was introduced into the re-written SFI0 
to permit this to be done using the Fortran READ statement. 
The manner of achieving this is shown by the following example: 
DIMENSION IA(l3) 
READ(99,101)IA 
101 FORMAT ('THIS -MESSAGE TO BE STORED 1 -) 
These" statements cause the EBCDIC equivalent of the characters 
contained in the FORMAT statement to be stored in IA. No modi- 
fication to the compiler is required. Characters are stored 
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Definition of Alphabetic Literals Using Fortran READ Statement cont'd 

two per word. If it -is desired to store characters one per word, 
..then appropriate spaces should be introduced in the field. . . 

This feature is particularly useful for the definition of masks 
to be used for editing operations. - 

^' Performance of the Subrout ine 

Using the Disk Monitor System, the subroutine is implemented by 
deleting from the disk the version of SF10 as supplied with the 
system. The subroutine PRNTZ must also be deleted. The sub- 
routines SFI^ and PRNXX, which form the overlapped output package 
are then substituted. Note that SFI0 can be stored as a subtype ^ 
2 program, which permits it to be included in SOCAL overlays. 
The subroutine PRNT1 supplied by IBM is also required as it is 
used to drive the 11^2 printer. Fortran programs should contain 
the record . j 

*I0CS(1132 PRINTER) I 
or I 
^ '*I0CS(ll32 PRINTER, DISK) 

depending upon whether disk- input /output is required. The 
-principal benefit to be derived from using -the method is the 
simplicity of coding. Also the processing speed which can be 
achieved using this subroutine is apparently identical to that 
achieved using the overlapped output subroutines supplied with 

' ' ' 
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Performa n ce of the Subr outine cont f d 

the Commercial Subroutine-Package. The core requirement for .- " 

SFI0 and PKSJXX is words VfQ, -which is somewhat in excess" of . . 
the equivalent subprograms supplied with the Commercial Sub- 
routine Package. However, this is offset -by the smaller core - 
requirements of- programs which use this method. As an example, 
one of- the sample programs provided with the Commercial Subroutine 
Package was modified to suit the overlapped input/output sub- 
routines. The processing speed was the same in both instances. 
Despite the smaller and simpler main_program when using the 
overlapped Fortran i/O, the total core requirement is somewhat 
larger, as is shown in the table below. For comparison, the 
. core requirements and processing speed using the normal Fortran 
input/output subroutines as supplied with the disk monitor system 
are also shown. 

Comparison of Typical Small 

Commercial Application ' 

CSP I/O Overlapped Standard 

Fortran l/O Fortran I/O. 



Main Program Statements 




102 


9 \ 


83 . 


Main Program Core Requirement 




978 


85O 


. 800 


Total size of Core Load 




5006 


5293 


^858 


Execution Time 




1 32 

min sec 


1 32 
min sec . - 


2 k$ 
min sec. 




Performance of the Subroutine cont'd 

The problem selected was .the invoicing problem which is included 

as Sample Problem 2 in the IBM- Commercial Subroutine Package, Version II. 

It is considered that for programs to produce large and complicated 

commercial reports, where the size of a core load becomes important, .. - 

the total core load requirement of programs using the output method 

described here would be smaller than would be required for the — ' 

same programs using the Commercial Subroutine Package; 



C 
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APPENDIX I 



Fortran Output Routine, with Overlap 
Users Guide. . ' . ,. 

This Is a program to replace the IBM library program SFI0, 
which is called for Fortran input/output operations. Its 
- purpose is to permit overlap of printing, card reading -and 
processing, for commercial applications. For this reason/ perr 
missible devices, allowable variable types and format field - 
specifications have been restricted. Only integer variables 
and arrays are recognized *ONE WORD INTEGERS option must be 
used. _ 

V7RITE . 

All writing is done on the 11^2 .printer, regardless of the 
device code appearing in the WRITE statement. If it is 
desired to write on the Console Printer or punch cards then 
an appropriate SUBROUTINE subprograms must be used. Data to 
be printed must be stored in EBCDIC or integer form as an 
integer variable or array. 

The following FORMAT field specifications are recognized:- 

A - for alphameric information. The only 

field widths recognized are Al and A2. 

Anything else is interpreted as A3., with 

no error indication. 
I for integer variables 



WRITE 1 , cont'd 



X for spaces 

H for printing alphabetic .Information. 

The form using quotes e.g. 
'- THIS MESSAGE ' may also be used. 
Field repeats e.g. 1-2A2 
The group repeat, e.g. 2(lKl, 12A2), will not be recognized. 
The maximum number of characters per line is 120, excluding the 
carriage control character. The use of E or F field specifications 
will cause the field to be filled with asterisks without 
further indication of error. 

The first character of a line will be treated as a carriage 
control character. The following characters are recognized: 

blank print on next line 

skip one line before printing 

1-6 skip to channels 1 to 6 

All other carriage control characters 
are treated a-s blank. 
The following errors will cause. a program stop with the error 
code displayed in the accumulator. 

EE01 line exceeds 120 characters 

EE02 invalid format- type 



READ 



No read statement, accepting information from an external medium 
is included. Appropriate SUBROUTINE subprograms must be used 
-for input from the card reader or console keyboard. The 
following statement is provided in order to generate alphabetic 
literal arrays • _ . 



KEAD(99>n). IA 
or 

READ(99>n) IA(I) 

KEAD(99>n) (lA(i),I=.-K,L) 

READ(99,n)((lA(l > j) > I=K,L),J=--M,N) 



which transfers H-type fields from fonriat statement ! n ! into 

.variable or array IA.' The characters will be stored in EBCDIC 

form, 2 characters per word. Only H-type fields are permitted 

in the FORMAT statement. If the number of characters in a 

field is odd, the rightmost character of the last word. is. filled - 

vith a blank. Characters will be moved until the array is 

filled. If the FORMAT statement is exhausted, "control will 

return to the last open bracket. The following errors will 

cuase a program stop with the error code displayed in the accumulator. 



This routine uses the IBM library subroutine PRNT1. Since printing 
occurs in overlapped mode, a call to IOND must be made before 
a PAUSE or STOP statement. - 



EE02 



format not H-type 



EE03 



device code not 99 
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READ cont'd 

The input/output routine requires the use of *I0CS-(ll32 • PRINTER). 
Since communication to the card-reader, or typewriter is through 
CALL statements to -subprograms which load the appropriate card 
or typewriter subroutines, then CARD, TYPEWRITER or KEYBOARD 
must not appear in the *IOCS record. 

Tracing may be used in con junction with this overlapped i/O . - 
routine. Since real variables are not converted by this routine, 
they will appear as asterisks in the tracing output. . 



APPENDIX II 

Loading the Overlapped Fortran Out put Routine 

Using the disk, monitor system, the following procedure is 
required. 

Delete SF10 arid PKNTZ 
■ Load the overlapped version of SFI$ 9 and PRNXX. 
Note that SFI0 can be designated: subtype 3 (punch 3 in coluinn 11 
of *STORE card), and hence can be included in SOCAL overlays, 
PRNXX cannot be included in overlays. - 

Core Requirements 

SFI0 " k$6 words 
PRNXX ' " 

470 " - 

The IBM supplied subroutine PRNT1 and from the Commercial, 

Subroutine Package are also required. 



// ASM 

*LIST SOURCE PROGRAM 



* LIMITED CAPABILITY I/O SUBROUTINE 

* WITH OVERLAP 











LI BR 






- 


0000 




22189580 




ENT ' 




SFIO 


■ - 


0076 




22645100 




ENT 




SRED 




0095 




229998C0 




ENT 




SWRT 




0013 




22256240 




ENT 




SIOI 




001F 




22256267 




ENT 




SIOIX 




0026 




22256049 




ENT 




SIOAI 


• 


002F 




22256180 




ENT 




SI OF 




0033 




220D6517 




ENT 




SCOMP . 




01C4 




176558E9 




ENT 




PRNT-Z 










# 


MAINLINE PROGRAM 


INITIALISATION 


0000 





1000 


SFIO 


NOP 








0001 


01 


66800003 




LDX 


12 




SET XR2- TO LIBF&l 


0003 





7212 




MDX 


2 


18 




0004 





6A01 




STX 


2 






0005 


01 


4C000007 




BSC 


L " 




"RETURN TO START OF 








* 


END 


OF 


MA I NL I NE 


INITIALISATION 








•* 


CALL 


ROUT I NE 





PROGRAM 



* RETURNS TO MAIN PROGRAM TO" GET 

*■ NEXT VARIABLE DESCRIPTION 



0007 





C030 


CALL 


LD 




LOOPS 


TEST FOR. I/O OF COMPLETE 


0008 





9069 




S 




0NE1 


ARRAY 


0009 


01 


4C08001 1 




BSC 


L 


RETRN t& 




OOOB 


01 


74FF0111 




MDX 


L 


VARAD»-1 


INCREMENT TO NEXT WORD-. I N 


OOOD 


01 


74FF0038 




MDX 


L 


L00PS»~1 


ARRAY 


OOOF 


01 


4C00003D 




BSC 


L 


DECOD 


GO TO DECODE ROUTINE 


0011 


01 


4C000013 


RETRN 


BSC 


L 




RETURN TO MAINLINE PROGRAM* 








* MAINLINE 


PROGRAM CALLS ONE OF FOLLOWING ENTRIES 


0013 





1000 


SIOI 


NOP 






ENTRY FOR- SINGLE INTEGER 


0014 


01 


66800016 




LDX 


12 


a 


SET XR2 TO LI8F&1 


0016 





C200 




LD 


2 





GET ADDRESS OF VARIABLE 


0017 





7201 


UP1 


MDX 


2 


1 


COMPUTE RETURN ADDRESS 


0018 


01 


D4000111 


SAVAD 


STO 


L 


VARAD 




001A 





C057 




LD 




0NE1 


SET LOOPS TO 1 


001B 





D01C 


LPSET 


STO 




LOOPS 




001C 





6AF5 




STX 


2 


RETRN&l 


SAVE RETURN" ADDRESS 


001D 


01 


4C0000BD 




BSC 


L 


DECOD 


GO TO DECODE ROUTINE 


QD1F 





1000 


SIOIX 


NOP 






ENTRY FOR SUBSCRIPTED INT* 


0020 


01 


66800022 




LDX 


12 


# 


SET. XR2 TO LIBF&1 


0022 





C200 




LD 


2 





GET ADDRESS OF VARIABLE 


002 3 


00 


84000001 




A 


L 


1 . 


MODIFY BY XR1 


0025 





70F1 




MDX 




UP1 


JOIN SIOI ENTRY 


0026 





1000 


SIOAI 


NOP- 






ENTRY FOR ARRAY 


002 7 


01 


66800029 




LDX 


12 


* 


SET XR2 TO L I 6 Ft 1 


0029 





C200 




LD 


2 





GET ADDRESS OF VARIABLE 


002A 


01 


D4000111 




STO 


L 


VARAD 




002C 





C201 




LD 


2 


1 


GET NOo OF ELEMENTS 


002 D 





7202 




MDX 


2 


2 


COMPUTE RETURN ADDRESS 


002E 





70EC 




MDX 




LPSET 


JOIN SIOI. ENTRY 



* - THIS ENTRY TO SATISFY LIBF SIOF 

* TRACE ROUTINESo JOINS SIOI 



IN 



002F 





1000 


SIOF 


NOP 


0030 


01 


66600032 




LDX 


0032 





70F3 




MDX 


003 3 





1000 


SCOMP 


NOP 


0034 


01 


66800036 




LDX 


003 6,, 





1810 




SRA 



12 * 

SI0I&3 



12 



16 



SET XR2 TO LIBFG1 
JOIN SIOI 

ENTRY FOR END OF OUTPUT 

SET XR2 TO LIBF-61 

SET LOOPS TO S<3j£ > 



00 3 I 





"7 A r~ o 

70E3 




MDX 




LPSET 


JOIN SI 01 ENTRY 


0038 




0001 


LOOPS 


BSS 




1 


ARRAY COUNTER 










END 


OF 


CALL ROUTINE 






_ 






HTYPE 


ROUTINE 














TRANSFERS H-TY^E 


CHARACTER 


S TO I/O BUFFER 


0039 


o ■ 


6200" 


HTYPE 


LDX 




2 


SET XR2 


AS CHAR -COUNTER 


003 A 





7201 


HL00P 


MDX 




2 1 


INCR* COUNT 


003b 


A 1 

J. 


440 00 11 4 




BSI 


L 


LINE 






U U 5 V 


A A 

UU 


/"/, A A A A A 1 

L4UUU002 




LD 


L 


2 


BIT 15 


OF XR2 TO CARRY 


003F 





1010 




SLA 




16 






0040 


A 1 

1 


C4 8 001 12 




LD 


I 


1FMT 


GET CHAR FROM FORMAT 


0042 


Q 


480 2 




BSC 




C_ 


SKIP IF 


. EVEN CHAR -- • 


0043 





180 8 




SRA 




8 


IF ODD * 


SHIFT RIGHT 


0044 





EQ30 




AND 




MASKR 


CLEAR GARBAGE 


004 5 


01 


44 0O.0 134 




BSI 


L 


10FI L 


MOVE TO 


. IOBUF 


004 7 


A A 

00 


C 4 000002 _ 




LD 


L 


2 


"MOVE FORMAT POINTER IF 


0049 


01 


4C04004D 




BSC 


L 


HODD* e 


SECOND 


CHAR IN "-WORD IS " 


004 8 


1 


-740101 12 


- 

- 


MDX 


L 


IFMTi 1 


. MOVED 




004D 





9026 


H0DD 


S 




FWIDE 


TEST FOR LAST CHAR « 


a a /. c 
04 c 


A T 

1 


4C28003A 




BSC 


L 


HLOOP»&2 


LEAVE WHEN DIFF "0 


0050 


A 



CO 2 3 




LD 




FWIDE 


END OF 


TRANSFER „ IF ODD NO 


0051 


A T 

1 


4C0400 54 




BSC 


L 


HENDjE 


OF CHARACTERS > MOVE FORMAT 


A A P. O 

OOP 3 





"? A £. A 

(06 9 




MDX 




DECOD 


POINTER 




0054 


A 1 

1 


740101 1 2 


HEND 


MDX 


L 


IFMT»1 






0056 





7066 


- 


MDX 




DECOD 














END 


OF 


HTYPE ROUTINE 








-- 


* 


XTYPE 


ROUTINE 














SKIPS 


OVER CHARACTERS IN I/O BUFFER 


005 7 





C01C 


XTYPE 


LD 




FWIDE 


SET XR2 


TO FIELD" WIDTH 


005 8 


00 


D4000002 




STO 


L 


2 






005A 


01 


440001 14 


XL00P 


BSI_ 


. L 


LINE 






005C 





7 2 F F 




MDX 




2 -1 


TEST FOR LAST CHARACTER 


0Q5D 





70FC 




MDX 




XLOOP 






a a r. c~ 
005 1 





"7 A CL C 

705 1. . 




MDX 




DECOD 












If 


END 


OF 


XTYPE ROUTINE 












AJYPE 


ROUT INE 












& 


TRANSFERS ONE OR 


TWO CHARACTERS FROM VARIABLE 










TO 


I/O 


BUFFER 






005r 


A 1 


44000 1 1 4 


a T\/nr 

ATYPE 


BSI 


L 


LINE 






a a a i 
0061 


A 1 

1 


C48001 1 1 




LD 


I 


VARAD 


TRANSFER 


LE-FT CHARACTER 


A A C O 

0063 





1 D A O 

1808 




SRA 




8 






A A £ y 

0064 


A 1 

01 


440001 34 




BSI 


L 


IOFIL 


STORE 




A A £ £ 

0066 





^~ A A A 

coop 




LD 




FWIDE 






A A A "7 
006 f 


u 


A A A A 
9 A 




S 




ON El 






A A A Q 

006 o_ 


_ 


«(• o o 


- 


BSC 










A A £ rf~T 

006 9 





•7 A r\ A 

f Q9D 




MDX 




CALL 






006 A 


01 


440001 14 




BSI 


L 


LINE 


TRANSFER 


RIGHT CHARACTER 


006C 


01 


C46001 1 1 




LD 


I 


VARAD 






006E 





E006 


- 


AND 




MASKR 






006F 


01 


440001 34 




BSI 


L 


IOFIL 






007L 





7095 




MDX 




CALL 






0072 





0001 


0NE1 


DC 




1 






0073 




pool 


FTYPE 


BSS 




1 


STORES 


FORMAT TYPE 


0074 




0001 


FWI DE 


BSS 




1 


STORES 


FIELD WIDTH 


0075 





00FF 


MASKR 


DC 




/OOFF 














END 


OF 


ATYPE ROUTINE 










* 


INITIALISATION ENTRIES 












SRED CALLED BY READ STATEMENT 


0076 





1000 


SRED 


NOP 











0077 


01 


66800079 




LDX 


12 


* • 


SET XR2 TO LIBF&l 


00 /9 


00 


C6800000 




LD 


12 





TEST DEVICE NO. f\ 


007 B 





901E 




S 




NlNTN 




K\ f\ ~1 J* 

007G 


01 


4C180084 




BSC 


■L- 


~ROK».&- 




007 E 


30 


09595 100 


DERR 


CALL 




IOND 


■ERROR*- DISPLAY /EE03 


0080 





CO IB 




LD 




EE 3 




0081 





3000 




WAIT 








0082 


00 


4C000038 




BSC 


L 


/3 a 


EXIT 


CK)84 





.1810 


ROK 


SRA 


- 


16 


SET READ SWITCH 


0085 


01 


D400010A 


SAVSW 


STO 


L 


READS 




0087 





C201 




LD 


2 


1 


GET FORMAT ADDRESS 


0088 


01 


D4 00 Oil 2 




STO 


L 


I FMT 




00'8A 





7202 




MDX 


2 


2 


COMPUTE RETURN ADDRESS 


00 8 B 





6A86 




STX 


2 


RETRNG-1 . 




008C 





1810 




SRA 




16 


SET INITIAL CHARACTER , 


008 D 


oi- 


D400014F 




STO 


L 


IOCHR - 


COUNT _ 


008F 


01 


C4000113 




LD 


L 


ONE 




0091 





DO 7 7 




STO 


- 


MULT 


- SET MULTIPLE FIELD COUNT 


0092 





D0A5 




STO 




LOOPS 


. SET ARRAY COUNTER . 


0.093 


01 


4C00O007 




BSC 


L 


CALL 


- - • - 


0095 





1000 


SWRT 


NOP 








0096 


1 


66800098 




LDX 


I 2 


Vr 


SET XR2 TO LIBF&l 


0098 





C07A 




LD 




ONE 


SET WRI-TE SWITCH 


0099 





70EB 




MDX 




SAVSW 




009A 





0063 


NINT.M 


DC 




99 




009B 





0003 


THREE 


DC 




3 




009C 





EE03 


EE3 


DC 




/EE03 





* END OF INITIALISATION 

* FIELD ROUTINE 

* TESTS FIELD TYPE 

* -TRANSFERS TO APPROPRIATE ROUTINE 









* 


TO MOVE 


TO I/O BUFFER - 


009D 





C0D5 


FIELD 


LD 




FTYPE 




009E 





906D 




S 




HCODE 


TEST FOR HT YPE 


009F 


01 


4C180039 




BSC 


L 


HTYPE»6~ 




O0A1 





8018 




A 




HXCOD 


TEST -FOR XT YPE 


-00A2 


01 


4~C180057 




BSC 


L 


XT YPE t£r- 




00 A4 


- 


9016 




S 




SXCOD 


TEST FOR -SLASH - 


00A5 


01 


4C2000AA 




BSC 


L 


AT EST »Z 




00A7 


01 


44000150 




BSI 


L 


PRINT 




"00A9 





7013 




MDX 




DECOD 




OOAA 


01 


74000038 " 


ATEST 


MDX 


L 


LOOPS»0 


TEST FOR SCOMP CALLED 


" OOAC 





7004 




MDX 




ATTST . 




00 AD. 


01 


44000150 




BSI 


L 


PRINT 




OOAF 


01 


4C000011 




BSC 


- L 


_ RETRN 




O0B1 





800A 


ATTST 


A 




SACOD 


TEST FOR A TYPE 


00B2 


01 


4C18005F 




BSC 


L 


AT YPE ♦ &-* 




00B4 





8005 




A 




HXCOD 


TEST FOR I TYPE . 


0065 


01 


4C180179 




BSC 


L 


. I TYPE »&- 




00B7 


01 


4C0801BF 




BSC 


L 


FETYPtfr 




.00B9 





7034 




MDX 




I NVAL 


INVALID FIELD TYPE 


OOBA 





0001 


HXCOD 


DC 




/0001 


HCODE-XCODE 


OOBB 





0003 


SXCOD 


DC 




/0003-. 


SLASH-XCODE 


- OOBC 





0004 


SACOD 


DC 




/0004 


SLASH-ACODE 


00 3 C 






IOBUF 


EQU 




/003C 


FORTRAN I/O BUFFER 










END 


OF 


FIELD ROUTINE 



* DECOD ROUTINE 

* EXTRACTS FIELD TYPE AND WIDTH FROM ^_ 

* FORMAT STATEMENT ^ SO 



* IF MULTIPLE FIELD* SETS MULTIPLE 

* FIELD COUNTER 

* IF END OF FORMAT STATEMENT * PRINTS 
*. • AND RESETS FORMAT SCAN. POINTER 









« 


IF READ 


V J i AAA 


* 


IK A i\ orb Kb LhAKAC 1 LKo 


oo Rh 

vvDU 


n 

- u 






l h 




Mill T 

MUL1 




] LST rOK MULTiPLt rltLD 


OORF 

V/ V C3 C 


n 
u 










AMP 
Ul\ t 




DDCUT Al ICI V CTAlli\n 

rKtv iUUoLY rUUlNU 


OORF 


1 

U J. 






DO V. 


• 

L 


u; || TP » 


L. 




UUv.1 


O 1 

U 1 


/~ /. O A A 1 '\ O 


-MHMI T 

(NUML 1 


1 h 


1 


. I FMT 




MAT Mill TTni C r 1 r 1 r\ />CT 

NO 1 MULTIPLE r I LLO * UET 


UUv J 


a 
u 


CU'fv. 




A M A 

AND 




MASK 2 




r OKMA 1 liPt AND DtCODt 


o a r/, 

U U v.'f 


a 
u 


nn/, a 
UU'+A 




C T A 

S 1 u 




WIDEC 




STORES WIDTH OR REPEAT 


a a ^* k 
UUC3 


U I 






1 A 

LU 


T 

I 


I FMT 






UUC f 


U 


- 1 OA/" 

loUC 




SRA. . 




12 




MOVE TO RIGH] DIGIT 


00C8 





DUA-P 




C TA 




TYPEC 




STORES TYPE CODE 


UULv 


O 1 
U A 


"7 A A 1 A 1 1 "3 


_ 


rl U A 


1 

L 


I FMT * 1 




INCREMcNT FCRiVAT P0 I N 1 ER 


UUv_b 


u 


O A "X P 

y U 5 r 




s 




FREPT 




TESi FOR FItLD REPEAT 




U 1 


/. V* O A A r\ A 1 

^•L^UUODi 




BSC 


L 


REDTS»Z 




/\ f\ f c~ 

OOCE 


Q 


C04-0 




L D 




wr dft 




FIELD R t PEAT » STORE 


a a c 


u 


a a ct o 




C TA 
i> 1 U 




MUl T 




NO* OF REPEATo 


a a aa 


A 

u 


*7 A O A 

f \) 5 U 




m r> y 




MULTF 






a a a i 


U 




K t 1) 1 S 






TYPEC 




TCcT C"At5 n rr> a /-r\f\ r ' 

TEST FOR REDO CODc 


oo ho 


A 
U 


O O "2 A 




c 
o 




REDO 






o o 


O 1 
U I 


a r 9 n a a t." 




Dot 


L 


SETF * Z 






a a a 


u 


CUjC 




1 A 




I FMT 

4 1 III 




REDO CODE FOUND 


A a ha 
UU Do 


A 
U 


y U.3L 




c 




ONE 




RESET FORMAT SCAN POINTER 


oo h7 

U U lv / 


A 

u 


QAQ7 




c 
o 




WI DEC 






U U u'O 


A 
U 


no ^ q 




O 1 \J 




I FMT 






00D9 

w vL/7 





^. V J3 C 




LD 




READS 




TpcT PD ft R P A h 


OODA 


1 

V J. 


*r \. w O \J \J \_ X 




BSC 


1 


N0MLT « 






OODC 


o 


A 7 3 




BS I 




PR I NT 




RFAD SWITCH NOT SFT 


OODD 


1 

V J. 


f 4000 3 ft 




1 D 


1 


LOOPS 




D P T f \! T » A f \1 h C f-' F C F O Q 


OODF 

V V.' L/ I 


1 


*+ V- £ V W V. J. 




BSC 


1 


N0MLT f 


z 




00 Fl 


01 


4C0000 1 1 




BSC 


i 


RETRN 






00E3 





r op A 

V. V t. r\ 


cPTc 
ot- i r 


LD 




TYPEC 




cpT F T F 1 h w 1 n T H A i\i h T Y P F 


00E4 


o 


DO A F 




ST0 




FTYPE 






OOFS 


A 


CO 7 Q 

v. V C. y 




i h 


- 


Wl DEC 






- oo fa 


A 

u 


no a n 








FW IDE 






00F7 

V U C- f 


A 

u 


ro 9 7 

v, U c 


F iV h h f~ 






READS 




Fma ap AF/"AATM^ p A O \/ a t ct 


OOFA 


1 


&r?ooo9r> 




r <^r 

D O v. 


1 


FIELD* 


z 




OOF A 



u 


r An c 
\.\J o o 




LD 




FTYPE 




RFAh cw J TfH cFT • T'c.T TYPF 
rs C A V O «¥ i I v_ n O I * I O I I T t l. 


OOFR 

v v/ C C) 


A 

V/ 


<?0? 




c 




HC0DE 






ooFr 

UUCV_ 


O 1 
U J. 






DOL 


L 


REPT » 6 






once 


D U 


riQuor, i a a 


T M V/ A 1 
I IN V M L 


C A 1 1 




I0ND 




T M\/ A I T h T V D P 


a a cr a 
UUr U 


A 


CU 1 c 




i h 




EE2 






nripi 
Uyr i 


A 
U 


*X A A A 
O U U U 




WA I T 

Wn i 1 










UUrt 


ho 
u u 


/i f~ O A O O 3 A 




DO v 


1 


/38 






no Fa 


O 1 
U J, 


- f II A A A A "7 /i 


P FP T 


I h 


I 


FWIDE 




CPT Mill TTDI P P I PI A mi IMTPD 
OCI l v IUL 1 I r Lt r IC LJJ v» U U l\ 1 LK 


a a p £. 


u 






A 

A 




ONE 




TA KlA r\ C l./ADAC T M U C T CI A 

10 Nu«ur WOKUb IN n ricLu 


OOP"/ 
UUr ( 


A 

u 


1 A A 1 
I O U 1 




CDA 
OKA 




1 






OO F A 
UU r o 


A 

u . 


ho l o 

UU 1U 




<; Tn 

O 1 u 




MULT 






o a po 
- UU r V 


A 1 
U I 


v.'1-o U U i 1 c 


T D A M p 


LD 


I 


I FMT 




TDAMCPPD ruADA^TPiJC TO 
IKA.NorLK V.MAKAL 1 CKo 1 U 


OOFB 


01 


D^800111 




ST0 


I 


VARAD 




VARIABLE 


OOFD 


01 


74010112 




MDX 


L 


IFMTtl 






OOFF 


01 


4C000007 




BSC 


L 


CALL 




TO CALL TO SEE IF DONE. 


0101 


01 


74FF0109 


MULTF 


MDX 


L 


MULT »- 


1 


" REDUCE MULTIPLE FIELD COUNT 


0103 





C006 




LD 




READS 






0104 


01 


't"C20009D 




BSC 


L 


FIELD* 


z 




0106 





70F2 




MDX 




TRANF 






0107 





000B . 


REDO 


DC 




/000b 




TEST FOR REDO INDICATOR 



0108 




0001 


. TEMP 


BSS 




1 




0109 




0001 


MULT 


BSS 




1 


MULTIPLE FIELD STORAGE . 


010A 




0001 


READS 


BSS 




1 


. FOR READ 1 FOR PRINT . <fj 
TEST FOR FIELD REPEAT W 


010B 





0009 


- FREPT 


DC 




/0009 


010C 





0005 


HCODE 


DC 




/0005 


TEST FOR H TYPE FIELD 


010D 





EE02- 


EE2 


DC 




/EE02 


ERROR DISPLAY- INVALID TYPE 


010*E 




OOOi 


TYPEC 


BSS 




1 


TEMPORARY STORAGE FOR TYPE 


01 OF 




0001 


WIDEC 


BSS 




1 


TEMPORARY STORAGE FOR WIDTH 


0110 





GFFF ". 


MASK2 


DC 




/OFFF 


- 


0111 




0001 


VARAD 


BSS 




1 


POINTS TO VARIABLE 


0112 




0001 


IFMT 


BSS 




1- 


"POINTS TO FORMAT STATEMENT 


0113 





0001 


ONE 


DC 




1 








-■ 




LINE' 


ROUT INE 










* 


CHECKS 


IF LINE IS 


FULL 








* 


DISPLAYS /EE01 IF 


FULL* OTHERWISE - 










INCREMENTS LINE COUNTER 








* 


IF START OF LINE* 


CHECKS PRINTER - 










READY 


> 


AND CLEARS 


I/O AREA 


0114 




0001 


"LINE 


BSS 




1 




0115 





C039 . 




LD 




IOCHR 


CHECK FOR START OF LINE 


0116 


01 


4C200124 




BSC 


L 


NOTST»Z 




0118 


20 


176558F1 


TEST 3 


l'ibf 




PRNT1 


START OF LINE, CHECK 


0119 





0000 




DC 




/OOOO 


PRINTER NOT BUSY 


011A 





70FD 




MDX 




TEST3 




011B 





6A06 




STX 


2 


SAV2&1 




one 





62C3 




LDX 


2 


-61 


CLEAR I /O AREA 


011D 





C015 




LD 




BLNKS 




011E 





D279 


STRBL 


STO 


2 


I0BUF&61 




011F 





7201 




MDX 


2 


1 




0120 





70FD 




MDX 




STRBL 




0121 


01 


66000123 


SAV2 


LDX 


L2 




RESTORE XR2 . 


0123 





7009 




MDX 




LINBK 




0124 





900D 


NOTST 


S 




LIMIT 


CHECK TOR LINE OVERFLOW 


0125 


01 


4C28012D 




BSC 


L 


LINBK »&Z 




0127 


30 


09595100 




CALL 




IOND 


OVERFLOW CLEAR INTERRUPTS 


0129 





C007 




LD 




" EE 1 


AND WAIT WITH ERROR DI SPLAY ~ 


012A 





3000 




WAIT 








012B 


00 


4C000038 




"BSC 


L 


/38 . 


EXIT 


012D 


01 


7401014F 


LINBK 


MDX 


"L 


IOCHR* 1 


NO OVERFLOW INCREMENT 


012F 


01 


4C800114 




BSC 


I 


LINE 


CHARACTER POINTER 


0131 





EE01 


EE1 


DC 




/EE01 




0132 


o - 


0079 


LIMIT 


DC 




121 


MAX e NOo OF CHARACTERS - 


0133 





4040 


BLNKS 


DC 




/4 040 


BLANKS - 








* 


END OF 


LINE ROUTIN-E 








- # 


IOFIL 


ROUTINE* ENTERS CHARACTER FROM 










ACCUMULATOR IN FORM OOXX INTO IOBUF 










IN POSITION GIVEN 


BY IOCHR 


0134 




0001 


IOFIL 


BSS 




1 




0135 





DO 15 




STO 




HOLD ~ 


SAVE ACCUMULATOR 


0136 





CO 18 




LD 




IOCHR 


CALCULATE ADDRESS TO 


0.137 





1881 




SRT 




1 


STORE-CHARACTER 


0138 





8015 




A 




IOADD 




0139 





D006 




STO 




AND&l 




013A 





1091 




SLT 




17 


"MOVE REMAINDER INTO CARRY ^> 


013B 





con 




LD 




MASKL 




n 1 '4 c 

\J X 3 v_ 


\J X 


'r v- \J C »J X -J I 




BSC 


L 


AND-, C 


IF CHARACTER NO* IS EVEN 


013E 





1808 ' 




SRA 




8 


"MOVE MASK TO RIGHT SIDE 


01 3F 


01 


E40003.41 


AND 


AND 


L' 


•5c 


DELETE UNWANTED CHARACTER 


0141 





DOOA 




STO 




TEMPI 


FROM DESTINATION WORD 


0142 





COOS 




' LD 




HOLD 


GET CHARACTER TO INSERT 9 
... - ; s.,y Cl ./L, 



« - 22- , L I 

; ; I 

i : 



0143 


01 


4C020146 




BSC 


L 


ORiC 


IF CHARACTER NO. IS EVEN 


0145 





1008 




SLA 




8 


MOVE CHARACTER TO LEFT 


0146 





E805 


OR 


OR 




TEMPI 


COMBINE ■ 


014 7 


01 


04 8 00 140 




STO 


I 


AND&l 


" STORE IN DESTINATION WORD 


0149 


01 


4C800134 




BSC 


"I 


IOFIL 


RETURN - 


014B 




0001 


HOLD 


BSS 




1 " 




014C 




0001 


TEMPI 


BSS 




• 1 




014D 





FF00 


MASKL 


DC 




/FFOO 




014E 





003C 


IOADD 


DC 




JOBUF 




014P 




0001 


IOCHR 


BSS 




1 


CHARACTER IN LINE 



* END OF IOFIL ROUTINE 

* PRINT ROUTINE 

* GETS CARRIAGE CONTROL . CHARACTER AND 











SETS 


UP 


APPROPRIATE 


SKIP 










PRINTS 


LINE. RESETS 


CHARACTER. POINTER " . 








if 


I-f START OF LINE-* T 


ESTS PRINTER READY ~ - - 


0150 




0001 


P RI NT 


BSS 




1 




0151 





COFD 




LD 




IOCHR 


- 


0152 


01 


4C080162 




BSC 


L 


TEST2 > 6 




0154 


00 


C400003C 




LD 


L 


IOBUF 


NOT -START OF LINE — 


0156 





901F 




S 




BLZ 


CARRIAGE CONTROL CHARACTER-"--" 


0157 


01 


4C2001 5B 




BSC 


L 


NUM»Z 




01"59 





CO ID 




LD 




SKP1 


IT IS Z-ERO* SKIP 1 LInE ■ 


0i5A 





7003 




MDX 




SKIP 




4)i5p 


_0 1 


4C.0Q0 165 


Ml 1 \.1 

NUM 


BSC 


L 


0UTLN>& 




ul 5D 





1008. 




SLA 




8 


IT IS A CHANNEL NO 


01 5 E 





E8 19 


SKIP 


OR 




CNTWD 


SKIP AS REQUIRED 


01 5F 





r\ r\ r\ 1 

D001 




STO 




CNTRL 




0160 


20 


176558F1 




LIBF 




PRNT1 


_ 


ft 1 A 1 
VIOL 


i 
l 


ft 1 A 




DC 








0162 


20 


176558F1 


TEST2 


LIBF 




PRNT1 


WAIT UNTIL SKIP' COMPLETE - 


0163 





0000 




DC 




/OOOO 




0164 





70FD 




MDX 




TEST2 




0165 





C0E9 


OUTLN 


LD 




IOCHR 


PRINT LINE 


0166 





1801 




SRA 




1 




£167 


00 


D400003C 




STO 


L 


IOBUF 




0169 


01 


4C200171 " 




BSC 


L 


PICALtZ 


TEST FOR ZERO WC - ~ - * ~ 


016B 





C0A7 




LD 




ONE 


IF COUNT IS ZERO 


016C 


-00 


D400003C 




STO 


L 


IOBUF 


MAKE COUNT 1 AND - - - 


016E 





C0C4 




LD 




BLNKS . 


PUT BLANKS IN I03UF & 1 


016F 


00 


D400C03D 




STO' 


L 


IOBUF&l 




0171 


20 


176559E7 


- P1CAL 


LIBF 




PRNXX 


PRINT WITH OVERLAP 


0172 





1810 




SRA 




16 




0173 





DODB 




STO 




IOCHR 




0174 


01 


4C800150 




BSC 


I 


PRINT 




0176 





40F0 


BLZ 


DC 




/40F0 


BLANK AND ALPHA ZERO 


0177 





0D00 


SKP1 


DC 




/ODOO 


CONTROL DIGIT FOR SKIP 


0178 





3000 


CNTWD 


DC 




/3000 


CONTROL FUNCTION -" . 



* - END OF PRINT ROUTINE 

* I TYPE ROUTINE 

*_ CONVERTS INTEGER VARIABLE TO DECIMAL 

* TRANSFERS DIGI-TS TO I/O BUFFER 

* IF FIELD. WIDTH TOO SMALL, FILLS FIELD 

* WITH ■ . . ~ 
ITYPE LD IOCHR SAVE POSITION OF- 

STO SAVCR CHARACTER POINTER 

LD L FW IDE -MARK POSITION CF RIGHT 

STO L 2 END OF FIELD, ALSO TEST - 



0179 C0D5 

017A D03C 

017B 01 C4000074 

017D 00 04000002 



-23- 



PA 



017F 


01 


44000114 


I LP 


BSI 


L 


LINE 




FOR SUFFICIENT SPACE 


0181 





72FF 




MDX 


2 


-1 




AVAILABLE IN LINE (f> 


0182 





70FC 




MDX 




ILP 






0183 





COCB 




LD 




IOCHR 






0184 





D033 




STO 




FEND 






0185 


01 


C4800111 




LD 


I 


VARAD 




GET ABSOLUTE VALUE OF 


0187 


01 


4C10018C 




BSC 


L 


POSV*~ 




VARIABLE 


0189 





1810 




SRA 




16 




IF NEGATIVE » CHANGE SIGN 


018A 


01 


94800111 




S 


I 


VARAD 






01 8 C 





D02C 


POSV 


STO 




VABS 






018D 





C02B 


OlVL 


LD 




VABS 




DIVIDE BY 10 


018E 





1890 




SRT 




16 






018F 





A82A 




D 




TEN 






0190 





D028 




STO 




VABS 






0191 





1090 




SLT 




16 




CONVERT- REMAINDER TO EBCDIC 


0192 





E828 




OR 




FZ 




- 


0193 





40A0 




BSI 




IOFIL 




STORE 


0194 





COBA 




LD 




IOCHR 




MOVE CHARACTER POINTER LEFT 


0195 





9028 




S 




ONE 2 






0196 





D0B8 




STO 




IOCHR 






0197 


01 


740001B9 




MDX 


L 


VABS»0 




TEST FOR ZERO QUOTIENT 


0199 





700E 




MDX 




NEXTD 






019A 


01 


C4800111 




LD 


I 


VARAD 




TEST FOR NEGATIVE VARIABLE 


019C 


01 


4C1001A4 




BSC 


L 


RESET 9 






019E 





COBO 




LD 




IOCHR 




TEST FOR SPACE FOR SIGN 


019F 





9017 . 




S 




SAVCR 






01A0 


01 


4C0 801AB 




BSC. 


L 


FILL$& 






01A2 





C019 




LD 




MINUS 




ENTER MINUS SIGN ({J 


01A3 





4090 




BSI 




IOFIL 






01A4 





C013 


RESET 


LD 




FEND 




RESET CHARACTER POINTER 


01A5 


.0 


D0A9 




STO 




IOCHR 






01A6 


01 


4C000007 




BSC 


L 


CALL 






01A8 





900E 


NEXTD 


S 




SAVCR 




NEXT DIGITe TEST FOR SPACE 


01A9 


01 


4C30018D 




BSC 


L 


DIVL*~ 


Z 


• AVAILABLE 


01AB 


01 


C4000074 


FILL 


LD 


L 


FW I DE 




NO SPACE • FILL FIELD WITH 


01AD 


00 


D4000002 




STO 


L 


2 




*** 


01AF 


01 


44000114 


FLP 


BSI 


L 


LINE 






01B1 


0. 


COOB 




LD 




ASTER 






01B2 





4081 




BSI 




IOFIL 






01B3 





72FF 




MDX 


2 


«1 






01B4 





70FA 




MDX 




FLP 






01B5 


01 


4C000007 




BSC 


L 


CALL 






01B7 




0001 


SAVCR 


BSS 




1 




RIGHT END OF PREVe FIELD 


01B8 




0001 


FEND 


BSS 




1 




RIGHT END OF THIS FIELD 


1 B9 




0001 


VAB5 


BSS 




1 




ABSOLUTE VALUE OF VARIABLE 


01BA 


o 


OOOA 


TEN 


DC 




10 






01BB 





OOFO 


FZ 


DC 




/OOFO 




CONVERTS DIGITS TO EBCDIC 


01BC 





0060 


MINUS 


DC 




/0060 




MINUS SIGN 


01BD 





005C 


ASTER 


DC 




/005C 






01BE 





0001 


0NE2 


DC 




1 














END 


OF 


I TYPE 


ROUTINE 








# 


FETYP ROUTINE 














F OR 


E 


TYPE* 


FILLS FIELD WITH *** jrx 


01BF 


01 


C4000074 


FETYP 


LD 


L 


FWIDE 






01C1 





E001 




AND 




NOD 




MASK OUT D PART OF SPEC. 


01C2 





70EA- 




MDX 




FILL62 


JOIN NO SPACE BRANCH 


01C3 





007F 


NOD 


DC 




/007F 














END 


OF 


FETYP ROUTINE 


01C4 





1000 


PRNTZ 


NOP 








DUMMY ENTRY NOT USED jj 

- i , — •■■ ■ - K~y-rfJ *'r 



-2k- 



c 



p/ 



01C5 70FE MDX *~2 

01C6 0001- BSS 1 

01C8 END 

NO ERRORS IN ABOVE ASSEMBLY* 




V 



-25- 



// ASM 

#LIST SOURCE PROGRAM 



0000 

0000 0" 

0001 01 

0003 

0004 20 

0005 

0006 

0007 1 

0008 01 
OOOA 1 
OOOB 01 
003 C 
OOOE 



176559E7 
1000 

C4000003 
D005 

176558F1 
2000 
003C 
OOOA 

4C00000A 
OOOB " 
4C80000A 



PRNXX 



BACK 
ENDPG 

10BUF 



PRNXX 

THIS 

LI BR 

ENT- 

NOP 

LD 

STO 

LIBF 

DC 

DC 

DC 

BSC 

DC 

BSC 

EQU 

END 



PRINTS IN OVERLAPPED MODE 
SUBROUTINE NOT OVERLAID DURING SOCALS 

PRNXX 

L * 

BACK&l • 

PRNT1 - 

/2000 

IOBUF 

ENDPG 



I ENDPG 
/003C 



SKIP TO CHANNEL 1 IF 
END OF PAGE 
FORTRAN I/O BUFFER 



NO E-RRORS IN ABOVE 'ASSEMBLY. 



// ASM 
*LIS'T 
00 



09595100 



0000 0001 

0001 00 74000032 

0003 70FD 

0004 01 4C800O00 
0006 



ENT 
*CALL IOND 
*CALL IOND 

IOND BSS 
IOPND MDX L 
MDX 

BACK BSC I 
END 



IOND . SUBROUTINE NAME 

NO PARAMETERS , 

ALLOWS I/O OPERA T-IONS TO END BEFORE 

PAUSE OR STOP IS ENTERED 

1 - ARGUMENT ADDRESS 

5040 ANY INTERRUPTS PENDING 

IOPND 

10 ID 



A 



IDEAL4«/f 
IDEAL48B 
I DEAL48C 
■I.DEAL48D 
IDEA1.48E 
I D-EAL4S F 
I DEAL48G 
I DEAL48H 
IDEAL48I 
IDEAL49 
I DEAL49 A 



NO ERRORS IN. ABOVE ASSEMBLY* 



S3? 



-27- 



3»22»3 



// JOB T ' - 

// FOR 

** SAMPLE PROBLEM 2 

*I0CS< 1132 PRINTER) \ 
*LIST ALL 

* NAME -SMPL2 - " - 

* ONE WORD INTEGERS 

* EXTENDED PRECISION 

C DEMONSTRATE USE OF OVERLAPPED PRINT SUBROUTINE 

C THIS PROGRAM IS IDENTICAL TO COMMERICXL SUBROUTINE PACKAGE 

C SAMPLE PROGRAM NO« 2 

C NOTE INPUT DATA CARDS CSP13960 TO CSP14030 ARE NOT REQUIRED 

C~— -THE INPUT IS MADE UP OF A MASTER CARD FOLLOWED BY THE TRANSACTION 

C' —CARDS FOR EACH CUSTOMER. WE WANT TO PRINT AN INVOICE AND PRINT A 

C — —NEW MASTER CARD FOR EACH CUSTOMER e 

DIMENSION INCRD( 8 2 ) » IPRNT (6) » I OTCD { 80 ) » I STOP ( b ) t I WK ( 13 ) * I SUM (8 ) » 
1IER0R(6) 

READ(99,101) ISTOP - - 

101 FORMAT ('ISTOP') 

READ(99»106) IEROR . 
106 FORMAT ('ERROR') 

J =2 

INCRD(81 )=16448 _ 
INCRD(82)=5440 

1 1 = 
L=0 

M=0 ' 

CALL READ ( INCRDtl » 80 * J ) 
IF(J-l) 22».2*2 

2 IF(NCOMP( I NCRD « 1 » 5 » I STOP 1 1 ) ) 

3 CALL NZONE( I NCRD > 70 ♦ 5 » K ) 
IF(K-l) 26,4*26 

WRITE (3 » 10 2 ) ( I NCRD ( I I) t 1 1 = 1 » 60 ) 
FORMAT ( ' 1' ,20Al/( « ' »20A1) ) 
READ(99,103) IW.< 

FORMAT ( ' t $ e C R 

CALL EDITUNCRD»61,68,IWK>1»13) . 
WRITE(3,104) IWK " - 

FORMAT ( ///10X» ' QT Y ' »10X» ' NAME ' »46X, ' AM T ' / 2 3 X ♦-' PREVIOUS 
128X»13A1) 
LINES=8 

40 CALL A1DEC ( I NCRD? 6 1 »6 8 » L ) 
I F ( L ) 5 ♦ 5 ♦ 2 3 

5 CALL MOVE ( I NCRD >6 1~» 68 ♦ I SUM 1 1 ) ~ ' ' 
CALL MOVE ( I NCRD * 1 $ 80 * I OTCD » 1 ) 

6 CALL READ ( I NCRD » 1 » 8 » J ) 
I'F(J-l) 22,7,7 

7 CALL NZONE( INCRD,70»5 »K) 
IF(K-l) 18,19>8 

8 I'F(K-2) 18,9,13 

9 IF<NCOMP(INCRD»1,20*IOTCD»1)) 18,10,18 
10 READ(99*110) IPRNT 

110 FORMAT ( « ♦ 1 ) 

CALL ED I T ( I NCRD ,49 » 52 * I PRNT » 1 »6 ) 

READ(99,103) IWK " 

CALL EDIT(INCRD,41,48,IWK,1,13) 

IF.(LINES~S5 ) 31 ,31 ,17 
31 WRJTE(3»10£j) I PRNT » ( I NCRD ( I I ) » I I 
10 5 FORMAT (7X,6A1 ,10X ,20A1 ,24X,13A1 ) 

L I NES=L I NES + 1 



4 

102 
103 



104 



) 



BALANCE » » 



21 ,40 ) » I WK 



CSP12820 
CSP.1^0 



CSP 12 84 
CSP12850 
CSP12860 



CSP12880 
CSP12890 
CSP 3.2900 



CSP13010 
CSP13020 
CSP13030 
CSP 1304 
CSP13050 
CSP13060 
CSP13070 

cspi?r v ' o 

CSP13M-0 
CSP13100 
CSP13110 



CSP1325C 
CSP13260 
CSP 13 270 
CSP13280 
CSP13290 
CSP13300 
CSP13310 
CSP 1-3 320 
CSP13330 
CSP13340 



^3? 



SAMPLE- PROBLEM 2 



PAGE 02 



p 



11 
1 

13 
14 



CALL A1DEC< I NCRD~*4 1 * 48 » L ) 



IF(L) 12* 12. 14 

CALL ADD ( INCRD>41 »48 * I SUM* 1 » 8 *M ) - 
IF(M) 13,6*13 
CALL I OND - " 
STOP 777 

CALL N20NE( INCRD»L»4*N1 ) 
N1 = - 
CALL A1DECUNCRD* L* L »N1 ) 
1F(N1) 16»16,15 

15 CALL IOND 
. STOP 666 

16 CALL DECA1 ( INCRD»41 *48 $L ) 
L = - 

GO TO" 11 
17 WRI'TE(3»109) 
109 FORMAT ( « 1 « *9X ♦ ' QT Y 1 »10X» 1 NAME 1 ,46X, « AMT • ) 
LINES^I 

GO TO 31 ~ 1 

18 CALL TYPER( IEROR* 1 t5 ) 
CALL TYPER ( INCRDrl $32 ) 
GO TO 6 

19 CALL DECA1(ISUM*1»8»L) 
IF(L) 20»21»20 

20 CALL IOND - .. _ 
STOP 555 " - 
READ(99»103) IWK""_ 

%J CALL EDIT ( I SUM » 1 » 8VI W K » 1 > 1 3 ) 
CALL MOVE( ISUMs 1>S» IOTCD»6 1 ) 
CALL TYPERCIOTCDi l.»80) 
WRITE(3,107) 1WK 
• 107 FORMAT(//23X»»TOTAL f \39X»13Al) 
CALL TYPERt lMCRD»ai-»82 J 
GO TO 1 

22 READ(99»108) IWK - 
-■"108 FORMAT ('E N D OF J- B ' ) 
- CALL TYPER ("I WK »1 » 1 ) 

CALL IOND 
. STOP 111 

23 CALL NZONE( INCRD*L»4»N1 ) 
N1 = " ^ 
CALL Al DEC ( I NCRD* L 9 L » Nl ) 

I F ( N 1 ) 25*25.24 

24 CALL LOiMD- 

_ STOP 444 ..." ~ 

25 CALL DECA1 ( INCRD*61 ?68 »L') 
L=0 

GO TO 40 - - 

26 CALL " TYPERUER"OR»l»5) 
CALL TYPER ( INCRD* 1 »82 ) 
GO TO .1 

END - - 



CSP 1343 
CSP 13440 
CSP13450 
CSP13460 
CSP13470 
CSP 1348 
CSP13490 
CSP13500 
CSP13510 
CSP13520 
-CSP 13 53 
CSP13540 
CSP 13550 
CSP13560 
CSP 13 570 



CSP13620 
CSP13630 
CSP 13 64 
CSP13650 
CSP13660 
CSP13670 
CSP13680 



VAWABLE ALLOCATIONS 
INCRD=0051 IPRNT^0057 IOTCO=OOA7 IST0P = 00AC I WX 
M =00CB K =00CC II =00CD LINES=00CE Nl 



CSP13820 
CSPI3830 
CSP13640 
CSP13850 
CSP13860 
CSP13870 
CSP13880 
CSP13890 
CSP13900 
CSP13910 
CSP13920 
CSP13930 
CSP13940 



;00B9 ISUM =00C1 IEROR=0OC v 
OOCF 



STATEMENT ALLOCATIONS 
101 =00F8 106 =00FF 



102 =0107 102 =0111 104 =0120 110 =0l3E 105 = 01< 



JAMPLE^gBLgM 

10 = 0243 31 
19 = 02DD 20 



= 01BD 


3 


-01C6 


4 


=01D2 


40 


= 0202 




= 020C 


= 02 65 


11 


=0288 


12 


= 0292 


13 


= 029F 


14 


= 02A3 


= 02 E7 


21 


=02.EB 


22 


= 0313 


23 


= 0322 


24 


= 0336 



gAGE \ 

It 6 



FEATURES SUPPORTED 
ONE WORD INTEGERS 
EXTENDED PRECISION 
IOCS 



CALLED SUBPROGRAMS 
READ NCOMP NZONE EDIT AlDEC MOVE ADD 
SFIO SIOAI SIOIX SUBSC- STOP - PRNT2 



IOND 



DECA1 TYPER 



INTEGER CONSTANTS 

99=00D2 2=00D3 
60=00DC 61=00DD 
4-8 = 00E6 55 = 00E7 

10=00F0 111=OOF1 



16448=00D4 
68=00DE 
21=00E8 
444=00F2 



5440=00D5 
13=00DF 
40=00E9 

1911=00F3 



= 00D6- 
8=00E0 
777=00EA 
1638=00F4 



1=00D7 
20=00E1 
4 = 00 EB 
1365 = 00FS> 



80 
49 
666 
27 3 



CORE REQUIREMENTS FOR SMPL2 
COMMON VARIABLES 



210 PROGRAM 



640 



END OF COMPILATION 





// XEQ 


: l 






CSP1395ot 



R 47 0B4E (HEX) WORDS AVAILABLE 




CALL TRANSFER VECTOR 



1123 
10D7 
10B2 
OC05 
OB5A 
0B3E 
0A7E 
0A40 
09D2 
08AF 
07FD 
07AF 
075D 

LIBF" TRANSFER VECTOR 



CARRY 

NSIGN 

FILL 

TYPER 

DECA1 

IOND 

ADD 

MOVE 

A1DEC 

EDIT 

NZONE " 

NCOMP 

READ 



O 



HOLL 


1 3AF 


PRTY 


135E 


FBPA 


1 30 F 

i. J w C 


TYPEO 


11E6 


EBPRT 


1180 


RPACK 


1050 


SUBIN 


1090 


AR6S 


1022 


SWING 


106F 


SPEED 


0ED6 


CARD1 


ODEO 


PRNXX 


0DD2 


PRNT1 


0C50 


STOP 


0B.44 


SCOMP 


054 7 


SIOIX 


0533 


SUBSC " 


087C 


SWRT. 


05A9 


SIOAI 


053A 


SRED 


058A 


ESTO 


06E0 


ELD 


06F6 


PRNTZ 


06D8 


SFIO 


-0514 


DISKZ 


00F4 


SYSTEM 


ROUTINES 


ILS04 


1401 


ILS02 


141D 


ILSOl 


142F 


ILSOO 


1441 



0338 (HEX) IS THE EXECUTION ADDR 



Tl 



OAVES MARKET 

1997 WASHINGTON ST. 

NEWTOWN* MASSe 02158 



o. 



#*\ "V \J 

QTY 


NAME * 


AMT 




finru t Al it- DAI A r 

PREVIOUS BALANCc 


- $13 1.29 


8 


SUGAR dAGo 


$2 1 * 02 


1 1 


CHICKEN oUUr — LAoto 


$3 8*76 


10 


1 UMA 1 O oUUr V.A0C.0 


$30 all 


8 


SUGA" REIUKNED 


$21 e ? C R 


6 


COOKIES *" CA5E5 


£45 « ? 3 


17 


^* T M f- t~ f~> Al C » ^*ACCC 

GINGER ALE *" CA0E0 


$52e37 

*P *^ C C — ' 4 


17 


ROOl BEER - CASES 


<F,5? * 37 


17 


ORANGE A0E - CASES 


J) ~> C Q ~> 1 


17 


CREME SODA " CASES 


<f> 5 ? « 3 7 


17 


CHERRY SODA - CAoEb 


£ 5v> e 3 7 


17 


SODA WATER CAbEi ._ - 


$52o37 


25 


DOG FOOD ~ CASES 




25 


CAT rOOlv — CA0E0 


£101.26 


10 — 


CHAD Dns/PlCP «*» f" A Q ST C 

oUAr ryvVUCr^ v. Mo Co 


$72»89 


. 10 


DETERGENT - CAbto 


£72 e 89 


12 


H AM — 1 i In 


$36.75 


12 


HAM - LOAr 


$33*75 


12 


r 11 tilt 

. SALAMI 


$33*75 


1^ 


r\ 1 r> fi m A 
bULUolNM 


$33c75 


1 2 




$33*75 


1 2 


KUAo 1 tit tr 


$33*75 


1 ♦ 000 


BREAD ~ LOAr 


$150*00 ." 


4 • 000 


DAI 1 C 

KOLLo 


$150*0(¥ ^ 


200 


M 1 L K UUAK 1 


$57e^A> 


100 


MlLK—HALr A L 


$57*^2 


53 


MILK ~ 0AL0 


$57*^2 


100 


POTATOES - BAoS 


$11*23 


100 


TOMATOES - LOOSc 


£ 1 1 P3 

4> X J. ft C 


100 


CARROTS - BUNCHES 


$11*23 


10 


DETERGENT - CASES 


$72*89 


12 


HAM - TINS 


$36*75 


12 


HAM - LOAr 


$33*75 


12 ■ 


r A 1 A M T ' 

5ALAM1 


$33*75 


12 


BOLOGNA 


$33*75 


12 


CUKNtiU DC. tr 


$33*75 


12 


KUAo 1 bttr 


$33.7-5 


ltOOO 


BREAD - LOAF 


$150*00 


4» 000 


ROLLS 


$150*00 


200 


MILK WUAKIo 


$57*42. 


50 


MILK" - GALS 


$57*42 


100 


MILK - HALF GALS 


$57*42 


100 


POTATOES - BAGS 


$11*23 


100 


- TOMATOES - LOOSE 


$llo23 


100 


CARROTS ~ BUNCHES ; 


$11*23 


10 


DETERGENT - CASES 


$72*89 


12 


-■ HAM - TINS 


$36.75 


1»000 


BREAD - LOAF 


$150*00 


4*000 


ROLLS 


$150*00 



01 Y . NAME 

200 MILK - QUARTS 

100 MILK - HALF GALS 

50 MILK - GALS 

100 POTATOES ~ BAGS 

100 TOMATOES ~ LOOSE 

100 CARROTS - BUNCHES 

10. DETERGENT ~ CASES 

1-2 HAM ~ TINS 

12 HAM - LOAF 

12 SALAMI 

12 BOLOGNA 

12 CORNED BEEF 

12 ROAST BEEF 

1»000 BREAD - LOAF 

4*000 ROLLS 

200 MILK - QUARTS 

_ 100 MJLK - HALF- GALS 

100 MILK - HALF GALS 

100 . POTATOES ~ BAGS 

100 TOMATOES ~ LOOSE 

100 CARROTS - BUNCHES 

10 DETERGENT - CASES 

12 HAM - TINS 



AMT 


(TC7 

3>3 / « 


hZ 


r e -7 


He. 


$57. 


42 


$11. 


23 


$11. 


23 


$llo 


23 


$72.89 


$36 o 


75 


$33 e 


75 


$3 3* 


75 


$3 3 © 


75 


$33 e 


75 


-$33o 


75 


$150* 


00 


$150. 


00 


$5 7. 


42 


$57. 


42 


$57. 


4 2 


$lle 


23 


$11". 


23 


$11. 


23 


$72. 


89 


$36 o 


75 



TOTAL 



$3»89~3*25 



■STANDI SH MOTORS 
10 WATER STREET 
PLYMOUTH* MASS*02296 



v>'.' 



QTY 


NAME 


AMT 




PREVIOUS BALANCE 


$2 » 356b 36 


20 . 


AIR CLEANERS - CASES 


S200o03 


6 


GREASE - BARRELS 


$165o24 


20 


TIRES - 650 X 13 


$260*38 


50 . 


TIRES - 7 50 X 14 . 


' $90.0 c5 3 


50 


TIRES - 800 X 14 


$1>012«00 


100 


GASOLINE CAPS 


$99*68 




TOTAL 


$4*994*22 



qp^^ c£ CP l ^ 




1130 COMMERCIAL SUBROUTINES 



ABSTRACT: 



Version II of the IBM 1130 Commercial Subroutines will be 
the primary emphasis of this session. The general problem of 
commercial programming in pure FORTRAN and the history of 
partial solutions available at this date will be discussed. 
Version II of 1130 CSP will be compared to Version I and other 
available commercial routines. Performance in execution time 
and core requirements as well as current limitations will be 
presented. 



J 



Comparison between 2310 and 2311 Disk Storage Systems 

S. F. Serous si 

Thomas J. Watson 
Research Center 
P. O. Box 218 
Yorktown Hts. , N. Y. 



A series of programs has been written to allow 1800 
users to fully utilize the capabilities of the IBM 2841-2311 disk 
storage system within the frame work of the Time- Sharing 
Executive -- TSX, Version 3, Modi. 

A comparison is made between the 2311 and the 2310 
disks in programming techniques and timing. 



Physical Characteristics 1 
2310 

Capacity - Oxide coated disk with 200 primary, 3 alternate 
2 track cylinders capable of storing 521, 304 16 bit words 
(1, 042, 304 bytes) of which about 512K words are available to 
the user the rest being used as alternates to defective tracks. 
Each track is divided into four sectors. A sector is the basic 
addressable unit with a capacity of 321 words one of which is 
usually used for sector addressing and error checkout. 

Timing - The disk rotates at a speed of 1500 rpm; 
a revolution taking 40 ms. Word transfer rate is 36 K words/ sec. 

Cylinder to cylinder access is 15 ms^in single steps 

or 20 for double cylinder steps and a delay of 20 ms must be 

added to allow the carriage to stabilize itself. Average access 
time 530 ms. 

Between sectors the shortest time available is 235ysec 
(plus Zlxjsec for each word not used). As an example, if we 
write 310 words in a sector and then continue to -write on the 
next sectors the delay between writes will be a minimum of 
235 + 27 x 11 or over half a millisecond. * 

Programming - The following hardware (machine 
language) operations are available: 

Models Al, A2, and A3. 



CE Mode 

INITIALIZE READ - 

INITIALIZE WRITE 
CONTROL (SEEK FORWARD OR BACKWARD) 
SENSE 

These operations must be executed one at a time with no 
chaining allowed and with several restrictions imposed such 
as the need for a 20 millisecond delay between seeks or an error 
will result. Only one sector can be processed per I/O command. 



Interrupts - Sensing the DSW for each disk unit provides 
the user with a series of indicators. The occurrence of an 
Operation Complete, causes an interrupt in the 1800. All other 
indicators will only be detected together with Operation Complete. 

Data Status Word 



Bit 


Interrupt 





Any Error 


1 


Operation Complete 


2 


Disk Not Ready 


3 


Disk Busy 


4 


Carriage Home 


5 


Parity Check Error 


6 


Storage Protect Error 


7 


Data Error 


8 


Write Select Error 


9 


Data Overrun 


10 


Not Used 


11 


CE Not Ready 


12 


CE Busy 


13 


Not Used 


14-15 


Sector Count 



READ TO MEMORY 
READ - CHECK 



Two or more indicators will be on when an interrupt occurs. 

Number of Drives Per System - Standard up to three, 
RPQ three more. 

Typical I/O Command: 

XIO IOCC1 



IOC CI DC 



DC 



TABLE DATA TABLE 

/4D01 WRITE ON DRIVE 1, 

SECTOR 1 



TABLE DC 



BSS 



321 



321 



COUNT 



A previous XIO would have moved the arm to the proper 
cylinder. 



4. 



2311 

Capacity - 12 oxide coated disks with the ten inside 
surfaces used;for recording data up to 7. 5 million 8 bit bytes. 

A pack is divided into 200 primary, three alternate 
cylinders and ten tracks (one for each recording surface) of 
3694 words each. Each track can be subdivided into records 
of variable length as defined by the user. The home address 
'which identifies the track and the first record on the track, 
RO, usually used to define the condition of the track (and its 
alternate if needed), are generated with special IBM provided 
programs with a standard format. A track would have the 
following configuration: 



Index Home 
Point Address 



-Record Rq- 



Record Rj, R2, R (n-1) 



Record R„ 



Index 
int 



Hlnc 
Po 

l I Counr J Key j Data A.M^ Count | [Key | | Data j |a.M.| Count | | Key | | Data | f\{ 



2311 Track Format 
Each of the above areas contains the following information: 



Index Home 
Marker Addresi 




Record R 



Dato Record R , 



Dora R( 



Flog 
Byre 


" r 

Cylinder Number 


T — 
Heod Number 
< 


• — r ■ ■ 

Cyclic Check 

. . 1 


Gop 


Record Rg j 





1 2 


i 4 


S 6 







Home Address 



5. 



Home Address Flag Byte ; The flag byte in the home 
address is transferred automatically to the using system by 
performing a read home address operation on the track. The 
bit significance is: 

Bit Function or Setting 

Zero 
Zero 
Zero 
Zero 
Zero 
Zero 

Track Condition 



1 
2 

Flog ' 3 
Byte^ * 
5 



Track Use 



indicate* operative track 

1 indicates defective track 

indicates primary track 

1 indicates alternate track 



Flag: Byte of the count area is generated by the 2841 
as each record is written. It is not sent from the CPU. Bit 
7=1 indicates an alternate track. 



Flog 
Byte 



Bit Function 

for even-count records (RO, l?2, R4, R^) 

1 for odd-count records (Rj , R3, R5 ) 

Used by the 2841 to ensure that all address 
markers (and records) are present . The 2841 
signals a missing address marker when two 
consecutive, identical bits are encountered 
(unless an index point intervenes). 

Used only with record overflow feature. 

for all non-overflow records ond for the last 
segment of an overflow record . 

1 for each segment, except for the last segment 
of an overflow record. 

2 Zero 

3 Zero 

4 Zero 

5 Zero 

6 Track condition indicates operative track 
1 indicates defective track 

Track Use Indicates primary track 

1 indicates alternate track 

Bits 6 and 7 are transmitted to the flag bytes of 
all records on the trcck from the flag byte J>f the 
Home Address of that track by the 2841 . 



6. 





Cyclic 




Check 



Flog 


Cylinder 


Head 


Rec. 


Key 


Data 


Cvclic 
Check 


No. 


No. 


No. 


Lath 


Length 



Y 

Count Area 



n r 

Key 



Cyclic 
Check 



Y 

Key Area 




Address 
Marker 



Index HA 




Address Address 
Marker * May Not be Present Marker 

Record R j - R n Format 



• Storage 
Units 


Track Capacity in Bytes 
When Rg is Used os Specified 
By IRM Programming Systems. 


Track Capacity 
When Rq is Used for 
ApplicaMon Data 


Bytes Required by Data Records (dl = |fc ^Length) 


Data Records (except for last record) 


Lost Record 


Without Key 


Wi»h Key 


Without Key 


• With Key 


23i r 


3625 


3694 


61+537 D 
512 L 


81*§f? (K L + D L ) 


°L 


20 + (K L + D L ) 



Number of Bytes per Record when 
Record Rq UJec ) os specified by 
IBM Programming Systems. 


Number of Equal Length Records Per 2311 Track 


1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


14 


15 


16 


17 


18 


19 


20 


Without Key 


3625 


1740 


1131 


830 


651 


532 


447 


384 


334 


295 


263 


236 


213 


193 


177 


162 


149 


138 


127 


118 


\»y»L v ) Includes key bytes + 
W,rhKe y {data bytes - K L + D L 


3605 


1720 


mi 


811 


632 


512 


428 


364 


315 


275 


244 


2'7 


194 


174 


158 


143 


130 


119 


108 


99 



Record gaps are of a length determined by the size of the 
record. Track capacity then, varies with record length as 
shown in the above figure. 

Timing - The disk rotates at 2400 rpm with a revolu- 
tion time of 25 ms. Access time from cylinder to adjacent 



cylinder is 25 ms; maximum access time (from cylinder 000 
to 200) is 135 ms and average time for a random access is 
75 ms. Once the cylinder is accessed, an average of 12. 5 ms 
is needed to reach the desired record. No delay is encountered 
in going from track to track because the access mechanism 
includes one read/write head per track. 

Programming - A series of commands each taking 3 
1800 words, are available to the user which allow for manipu- 
lation of both the control unit and the 2311 drives. These commands 
can be classified into four groups as recognized by the selector 
channel: Output Forward (Write, Control) 

Input Forward (Read, Sense) 
Branching (Transfer in Channel) 
Test I/O 

There are forty possible command codes^^ some of which allow 
the user to operate on any of the elements contained in a track 
or in a whole cylinder. There is no capability to cross 
cylinder boundaries. This has to be programmed for and is 
very simple. 

Interrupts - Before considering the interrupt capabilities 

of the 2841-2311 system let us look at a simple diagram of one 

of these devices connected to an 1800. 

!♦ See Appendix I, pp I. 2 for table of commands 



8. 



1800 1826-M2 



Selector Channel 




2311 Q 

From this diagram, it is evident that there are two interface 
of importance; (1) Selector Channel/ Control Unit (2841) and 
(2) Control Unit/I/O Devices (2311). 
Selector Channel/ Control Unit 

(a) If more than one control unit is attached to the 
selector channel, SENSE ILSW will determine which one of 
them has interrupted. The machine configuration under 
consideration has one control unit so there is no need to 
execute this instruction. 

(b) To determine the status of the selector channel, 
SENSE CHANNEL STATUS WORD can be executed. It is a 
similar step to sensing DSW on the 2310. It provides the pro 
grammer with the following information in the accumulator; 



9. 



BIT 




8 



STATUS 



Not Operational 



Unit Status Pending 



Program Control 
Interrupt 



Program Check 



Data Check 



Interface Check 



Incorrect Length 



Channel Busy- 



Unit Operational 



MEANING 

Device Addressed not ready 
or not connected 

Control Unit and Device Status 
Waiting for Further Action 

Requested by Programmer 



Bad Parity on IOCC - Request 
Out of Bounds 

Parity Error - Write to 
Protected Area 

Hardware Error 

Requested Length and Length 
in Disk Unequal 

Busy - Do not Request Another 
I/O or Card Check will Occur 

Unit Up - Actually In Use 



The first four conditions generate an interrupt. Further 
information can be obtained from the status of the control unit 
and devices. 

4 

Control Unit/ Devices 

Up to eight 2311s can be attached to a single control 
unit. To obtain their status, a SENSE UNIT STATUS can be 
executed. If Unit STATUS PENDING occurred, it is necessary 
to do this sense in order to clear the interrupt. The 16 bits 
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of information placed in the accumulator are: 



BITS 


STATUS 


MEANING 


0-3 


- 


Address of Control Unit 


4-7 




Device Address (0 - 7) 


8 


Attention 


Not Used 


9 


Status Modifier 


With 11, Control Unit Busy 


10 


Control Unit End 


Control Unit Available 


11 


Busy 


With 9 


12 


Channel End (CE) > 


Indicate Status 


13 


Device End (DE) J 


Of Operation 


14 


Unit Check 


Error 


15 


End Exception 


End of File Detected (A 
Record with Zero Count) 



The above bits can be on in several combinations depending upon 
the operation in progress. In general, CE - DE together and 
alone, indicate a successful end of operation. Unit Check on 
the other hand, indicates an error. Three more sense operation 
are available to assist the programmer in determing the error 
source: 

(a) SENSE CCW ADDRESS - will give the address plus 

three of the last commands used. 

(b) SENSE BYTE COUNTER - will give the residual 

byte count. 

(c) SENSE BYTES - will transfer six bytes of informa- 
tion concerning the unit check from the 2341 to the CPU at an 



address specified by the user. The first two bytes contain 



most of the needed information as shown below: 



Byte Bit Desigrvi^ -• Significance of "I* 



Byte Bit Designation Significance of " 1" 



Command 
Reject 



1 Intervention 
Required 



2 Bu» Out 
Parity 
Check 



3 Equipment 
Check 



4 Oata Check 



5 Ov 



Indicotes that the 2841 has received an invalid 
operation code, an invaltd sequence of com- 
mands, on invalid Seek Address, The write 
portion of the file mask has been violated. 
(See Set File Mask.) 

Indicates that the specified file if not physically 
attached to the system or, if physical ly attached 
to the system, it Is not available for use because 
the file motor is not on, a cover interlock it 
open, etc. 

Indicates that the 2841 has detected a parity 
error during the transfer of a command or data 
from the channel to the 2841. A parity error 
detected during command transfer signals a 
Parity Check. 

Indicates that an unusual condition is detected 
in the control or storage unit. Conditions 
covered by this bit ore defined by Sense Byte 2 
(See Appendix B) . 

Indicates that a data check error has been de- 
tected in the information received by the 2841 
from the storage unit. 

Indicates that a chained CCW was issued but It 
was received too lote to be properly executed; 
or that a byte was received too lote (during 

operation) to be transferred properly; or 
the chonnel did not respond fost enough during 
a read or search . 

When writing, the remaining portion of the 
record area Is filled with zeros and the overrun 
check is generated. When reading or searching, 
the remaining portion of the record is ignored. 

Indicotes defective track. 

A Track Condition check is generated under the 
following conditions: 

1. If an overflow record is being read, written, 
* or searched which overflows to a defective 

track, the interrupt occurs after the last 
byte on the previous track has been operated 
on and before the first byte for the defective 
track is requested from or sent to the channel. 
In this case overflow incomplete Is also set. 

2. If a single track command other thon a 
Search HA, Read HA, or Read RO is executed 
on o defective track. 

3. If a multiple trock command or an overflow 
operation attempts to switch from an alter- 
nate or defective track after an operation 
has been executed. 

7 Seek Check Indicates that the file has been unable to com- 
plete a Seek because: 

1. The Seek address is outside the valid address 
boundaries of the storage device. Unused 
seek address bytes must be a valid address 
for the device selected. Command Reject Is 
also set. 

2. Less than six seek address bytes were sent. 
Command Reject is also set. 

3. The equipment failed, which resulted In the 
access mechanism going to either the Inner 
or outer stop. 

Data Check Indicates that cyclic check error has been de- 
in the Count tected in a Count Area read from the storage 
Field device. Oata check (bit 4) \i% byte Is also 

turned on. 



Trock 

Condition 

Check 



I 1 Track 

Overrun 

1 2 Cylinder 
End 

I 3 Invalid 

Sequence 



4 No Record 
Found 



5 File 

Protected 



1 6 Missing 
Address 
Marker 



1 7 Overflow 
Incomplete 



Indicates that writing has not been completed 
by the time the index point is detected. 

Indicates that Cylinder End has been detected, 
but the CCW Command Chain has not been 
completed. 

Indicates that on attempt has been made to 
execute an invalid sequence of CCWs or that 
two Set File Mask commands appear in the 
same command chain. 

Valid command sequences ore defined in the 
Write ond Erase command descriptions. Com- 
mand Reject (Byte bit 0) is also set when an 
Invalid sequence is detected. 

Indicates that while executing a chain of CCWs 
the 2841 has dsfecfed two Index Points without 
completing an intervening command to read or 
write or search the Data Area, Read Home 
Address, or Read RO. It is also set in 
conjunction with Missing Address Marker if 
there is no data on the track. No Record Found 
is never set if the Multi -Track bit in the com- 
mand (Bit 0) is on . No Record Found will be 
posted if the address marker in front of the last 
physical record on the track is not detected. 

Indicotes that a command was issued contrary to 
the file mask. The Command Reject bit is ai$o 
set by this condition, if the operation violates 
the write portion of the file mask. 

A missing Address Marker, which may Indicate 
a missing record is detected during the execu- 
tion of command or chain of commands which 
operates on successive Count Areas on a trock. 
The condition detected is two successive records 
on a trock with equal bit conditions in bit of 
the Flag bytes, with no intervening Index Point. 
Missing Address Marker is set in conjunction 
with No Record Found if there is no data on the 
trock. 

This bit is used with the Record Overflow 
special feoture. It Is set with other Indicators 
to signal conditions as follows: 



Condition 

Overflow to o 
defective trock 

Overflow from an 
alternate track 

Data check in data 
area of overflow 
record other than last 
segment . 

Overflow to File 
Protected boundary 

Overflow to wrong 
track (Head number 
unequal) 



Sets Overflow 
Incomplete and 
Other Indication 

Track Condition 
(Byte 0, bit 6) 

Track Condition 
(Byte 0, bit 6) 

Data check 
(Byte 0, bit 4) 



File Protected 
(Byte 1, bit 5) 

Seek Check 
(Byte 0, bit 7) 



Sense Bytes and 1 



SSI 
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Typical I/O Command: READ HOME ADDRESS; CYL 180-HEAD 8 



XIO SIO 



START I/O 



SIO 



DC 
DC 



CCW 
/9502 



START I/O - IOCC 



AREA CODE 18 - UNIT 2 



CCW r DC 
DC 
^DC 
/"DC 

tDC 
DC 

SEEK DC 



5 

/4007 
SEEK 
6 

/001A 

HOME 





DC 180 
DC 8 



SEEK AND CHAIN 

FOR RECORD SPECIFIED 
AT SEEK ADDRESS 



READ HOME 
ADDRESS INTO 
THIS ADDRESS 

CYLINDER 
HEAD 



HOME BSS 
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Software 

The available software for the 2310 is well known to 
most users. In brief, there are programs to initialize the 
disk cartridges, test them for errors, label and define length 
of LET and FLET tables, and dump their contents when needed. 
Both FORTRAN and ASSEMBLY LANGUAGE routines are 
available to read and write to almost any area on the 2310 
disks. System routines will define and label at your request 
buffer areas and will assign sector addresses. All the user 
has to do is punch a define file card, or a STOREDATA card 
and the system will do the rest. Moreover, all of this is 
usually done with re-entrant subroutines enabling the user to 
be free of worries about using a device from different interrupt 
levels. The only penalty paid, as the sample program v/ill 
show, is time and overhead costs. All 2310 routines eventually 
call an I/O subroutine, DISKN which has been charged wijh 
the responsibility of controlling all I/O to the 2310s and 
servicing the resulting interrupts. It should be noted that 
FORTRAN calls are not overlapped, i. e. , control is returned 
to the user after the operation has been completed successfully 
or not. 

The software available for the 2311 as provided 
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is restricted to diagnostic programs and a disk initialization 
program. TSX does not support the 2841-2311 but programs 
have been written which allow the 1800 FORTRAN and 
ASSEMBLY LANGUAGE user to fully utilize the 2841-2311 
capabilities. These routines are at the present time being 
submitted a s Type IV programs!^ Work in switching 
TSX to the 2311 is also being contemplated. The structure 
of these routines is similar to those used to service the 2310s 
but three differences must be mentioned: 

(1) The routines are not re-entrant. Given the speed 
of data transmission, it is possible to mask any interrupts 
while the 2311 routine is generating a chain of commands 
prior to executing the I/O. The time delay is comparable to 
the time it would take to save and restore all needed parameters 
if made re-entrant. 

(2) The I/O can be overlapped. The return to the 
user is made immediately as soon as the I/O is initiated. The 
user has the option to examine the final interrupt to determine 
if the operation was successful or not or to ignore this fact 
completely and continue with his program. 

(3) The different I/Os are requested through calling 

sequences. There is no special WRITE or READ as in the 
!• See Appendix II for further explanation and examples. 
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2310, and most of the parameters in FORTRAN must be fixed 
Integers. There are 10 calls that can be used to generate a 
sequence of instructions that will perform a certain I/O on the 
2311 and two auxiliary calls> one that allows the user to write 
his own command chain and the other a busy test routine. In 
machine language, a third special call allows the user to get 
to a table of parameters and indicators saved by the 2311 ISS. 
As in the case of the 2310, the 2311 calling sequences execute 
all If O through a subroutine, DISKZ. 

Having provided a brief sketch of the software available 
for both 2310 and 2311 disk storage devices, it is possible now 
to look at the programs run to obtain some timing comparisons. 
The philosophy used was very simple; write and read back a 
fixed length record to both disk units under similar conditions 
and record the lapsed time between start and finish. 

TIMING 

Time 



Routine WRITE -RE AD I/O 2310 2311 language 

TIME1 3200 words 7.188 sec. . 322 sec. FORTRAN-TSX 

TIME 2 3200 words • 1. 609 sec. ASM-TSX 

TIME3 3200 words .192 sec. ASM-TSX 

$TIME 320 words . 262 sec. ASM-ABS 

TIME4 320 words . 918 sec. ASM-ABS 



16 



It should be pointed out that a data area for use of all these 
routines was set up in FLET and unprotected by means of 
DWRAD. This time was not included in the computations,, 
Also, the time shown for $TIME does not correspond to a 
single write of 320 words but to five repeated attempts to 
write the same record. This was caused by an error in one 
of the routines used and shows the timing effect of retrying 
an operation that failed with a recoverable error {in this 
case unrecoverable). 

It is evident that the use of FORTRAN for disk i/O in 
stead of Assembly Language is costly for the 2310 but that 
in the case of the 2311 storage devices, at the present time, 
the difference is quite tolerable. 



PHYSICAL CHARACTERISTICS 

2310 2311 

1. 02 STORAGE CAPACITY (MILLION BYTES) 7. 5 

530. 00 HIGH SPEED ACCESSIBILITY (milliseconds average) " 75. 

7 2. 00 DATA TRANSFER (KILO BYTES) 156. 

3 MULTIPLE UNIT GROWTH 8 

203 NUMBER OF CYLINDERS 203 

2 NUMBER OF TRACKS/ CYLINDER 10 

5. 1 CYLINDER CAPACITY (THOUSAND BYTES) 37. 

SECTOR BASIC ADDRESSABLE UNIT RECORD 

640 v MAXIMUM CAPACITY OF BASIC UNIT (BYTES) 3900 
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II. 1 

The 2841 and 2311 Subroutine Package 

The 2841-2311 subroutines were written to allow FORTRAN 
and/or Assembly Language users to avail themselves of 
these high speed storage device s. 

The aim was to organize the routines along the lines 
of the 2310 support programs. To accomplish this, a set of 
three subprograms were developed: 

1) The interrupt service subroutine (ISS), DISKZ, 
that handles all I/O requests through its subroutine 
entry point and takes care of all resulting inter- 
rupts informing the user, if he cares to know, of 
the status of the last I/O executed. 

2) Ten calling sequences which operate upon all or 
any element of a record, track or cylinder (see 
Table I). 

3. One additional subroutine with three entry points: 

(a) One entry point, DISKX, which allows the 
user to write his own command chain and calls 
DISKX to execute the I/O and handle the interrupts, 

(b) An entry point T2311 to a routine busy test* 
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'An indicator is set to zero or one according to the 
busy status of DISKZ 
4) A dummy entry point X8Y9<{> to a table of para- 
meters and indicators kept by DISKZ. 

DISKZ performs the same functions for the 2311 as 
DISKN does for the 2310. The other subroutines determine 
which operation is to be performed by the 2311. 



TABLE I 



2311 CALLS AVAILABLE UNDER 1800 TSX 



CALL 
CALL 
CALL 
CALL 
CALL 
CALL 
CALL 
CALL 
CALL 
CALL 
CALL 
CALL 
CALL 



WR 

WRO 

WKD 

WD 

RHA 

RRO 

RCKD 

RC 

RKD 

RDD 

DISKX 

T2311 

X8Y94> 



WRITE COUNT, KEY AND DATA 

WRITE SPECIAL COUNT KEY AND DATA 

WRITE KEY AND DATA 

WRITE DATA 

READ HOME ADDRESS 

READ TRACK DESCRIPTOR. RECORD 

READ COUNT, KEY AND DATA 

READ COUNT 

READ KEY AND DATA 

READ DATA 

DIRECT CALL TO DISKZ 
DISKZ BUSY TEST 

ENTRY POINT AT BEGINNING OF TABLE 
KEPT BY DISKZ (DUMMY CALL SHOULD 
NEVER BE EXECUTED) 



All these calls have a variable number of parameters. For 
further information contact: 

R. C. Yens 

The Mitre Corporation 

Command and Management Systems 

Planning and Engineering, D-74 

P. O. Box 208 

Bedford, Massachusetts 01730 
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C EXAMPLE OF 2311 CALLING SEQUENCE IN FORTRAN 

C 

EXTERNAL RET 

INTEGER AU53),BU53) 
C • ESTABLISH ADDRESS OF RECORD TO BE WRITTEN BY APPENDING TO DATA 

C THE CYLINDER, HEAD AND RECORD NUMBER DESIRED (KEEPING IN MIND • 

C THAT ARRAYS ARE STORED FROf-i HIGH TO LOW CORE IN THE IBM 180.0) 

C 

C CYLINDER 
C 

AU53> = 100 

C 

C HEAD 
C 

AU52)= G 

C 

C • RECORD NUMBER AND KEY LENGTH IN THE FORMAT RRKK MUST BE GIVEN ' 

C IN THE DECIMAL EQUIVALENT OF THE HEXADECIMAL NUMBER 

C IN THE EXAMPLE THERE WILL BE NO KEY SO THAT FOR RECORD NUMBER 1, 

C THE HEXADECIMAL NUMBER WILL BE 0100 OR DECIMAL 256 

AU51>« 256 . 

C 

C WRITE COUNT KEY AND DATA 

C 

CALL WP;(RET,1,1,AU53)) 

C 

C READ COUNT KEY AND DATA 

C 

CALL RCKD(RET,1,100,6,1,CU53) ) 

C 

C V/AIT FOR END OF OPERATION 

C 

10 CALL T231K1) 

IF(1.)10, 15,10 • 
15 CALL DMPP(A(1), BU53)) 

20 CALL EXIT 

Cs, END 

- 
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c 

C CALL RET (KK) !S A USER WRITTEN SUBROUTINE TO HANDLE ALL NORMAL 

C • AND ERROR ROUTINES - KK IS AN INDICATOR PASSED TO THE USER 

C BY THE INTERRUPT HANDLING SUBROUTINE, DISKZ 

C ' . 

C 

SUBROUTINE RET ( KK ) 
CALL DMPP(KK) 
RETURN 
END 



r 
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0000 



045175C0 



ENT DMPP 

DMPP SHOULD BE A USER WRITTEN SUBROUTINE 
TO DUMP IN HEXADECIMAL THE ARRAYS DELIMITED 









* BY T! 


E 


GIVEN 


PARAMETERS 


0000- 





0000 


DMPP DC 




* - * 




0001 


01 


7U02000Q 


MDX 


L 


DMPP, 


8x2 


0003 


01 


<*C80000Q 


CSC 


1 


DMPP 




0006 






END 




DMPP 
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This paper will present the progress made by Trans -Canada Pipe 
Lines Limited, Toronto, in the field of process control computers . A 
brief description is given of the feasibility study prior to ordering the 
computer, the organization of the implementation team and the methods 
of implementation. 

The purpose of installing the process control computer at Trans- 
Canada is to save fuel by more efficient operation of compressor stations, 
and to guide the dispatcher into better control of the line, thus allowing 
more throughput at the same or better operating cost. The computer is 
not closed loop, but accepts telemetered data from all compressor stations 
on a priority interrupt basis, optimizes the line by means of an on-line 
simulation program and then informs the dispatcher by typewriter output 
what changes, if any, to make to achieve optimal operation. 

A description is given of the telemetering system that feeds the 
computer and of the simulation/optimization program that is used to control 
the line. The computer, the IBM 1800, was installed in June 1967. 
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1 . Introduction 

As pipelines become more and more complicated, it is becoming 
increasingly difficult for the dispatcher to run his line with a high level 
of efficiency. This, of course, does not reflect on the dispatcher's ability 
but rather is a direct result of the tremendous number of variables that 
have to be controlled, especially in a line that is running at a high load 
factor. To make an intelligent analysis of the line the dispatcher has to 
know the flow through each compressor station, the horsepower available, 
the number of units running at each station, RPM of the engines, surge 
restrictions and the sales pattern. 

The answer to this problem has to lie with the on-line process 
control computer. There are many fast, reliable and relatively inexpensive 
computers that, when connected to a good telemetering system, can provide 
answers quickly and accurately to the dispatcher. I would like to discuss 
briefly the results of having installed a 1710 in September 1965, and later 
an 1800 in June 1967, at Trans-Canada Pipe Lines Limited. 

2. Description of T. C. P. L. 's System 

Trans -Canada Pipe Lines Limited owns and operates one of the 
longest natural gas transmission lines in the world. It stretches 2,300 
miles from the Alberta-Saskatchewan border to Montreal and to export 
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markets in the United States. In the domestic market it sells gas to 11 
distribution companies. 

Trans -Canada's main activity is the purchase, transportation and 
sale of natural gas. The original system was completed on October 10, 
1958. As a result of the wide acceptance of this fuel, the system has been 
constantly expanded, and as at December 31, 1966 it consisted of 2,900 
miles of pipeline including loop-line. The investment in facilities is close 
to $600 million. 

The present system can deliver up to 1.4 billion cubic (eet of gas 
per day. About 95% of the gas enters the system at the Alberta-Saskatchewan 
border, and takes about three days to reach Montreal, To give you an idea 
in terms of equivalent B. T. U. 's this is equal to over 200, 000 barrels of 
fuel oil or about one -fifth of the current Canadian production and consump- 
tion . 

The power to transport the gas is provided by 111 compressor units 
totalling about 550,000 horsepower. To give you an idea: 

An outside view of reciprocating station. 

An inside view of a reciprocating station, high 30,000 
H. P. , $7.5 mm. 

An Orenda industrial gas turbine. 

A compact, fully automated jet station, 9- 12,000 H.P. , 
$1.5 mm . 



These units, most of which burn natural gas, are grouped into 
45 highly automated compressor stations. This makes for a bewildering 
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combination of power units and compressors, each with its own operating 
characteristics and restrictions. 

3, Statement of the Problem 

The problem has generally been outlined in the "Introduction", that 
is, there are too many variables in a large pipeline for the dispatcher to 
effect ively control the line. Specifically at T. CP. L. the aim of the 
process control computer is to save fuel by more efficient operation of 
compressor stations and to guide the dispatcher into better control of the 
line thus allowing more throughput at the same or better operating cost. 
With the fuel consumption being in the order of 100 million cubic feet per 
day, it would only take a one percent saving to make the system pay for 
itself. In addition, from five to twenty million cubic feet of additional 
throughput can be achieved on some days that the line has upset conditions, 
by giving the dispatcher better operating data quickly. 

Since Trans -Canada Pipe Lines is designed such that all the gas 
that is moved can be sold, the above figures can be translated into direct 
additional revenue and are not merely paper savings. 

4. Feasibility Study 

In the early part of 1963 management approved the starting of a 
feasibility study for the installation of a process control computer. A 
task force was formed consisting of the Supervisor of Programming, 
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together with two part time representatives from Engineering and Operations 
departments. The task force reported to the Manager, Systems and Data 
Processing, and regular monthly reports were issued to management. 
Outside consultants were also introduced to work with the task force and 
advise primarily on selection of hardware. 
The task force concentrated on: 
I. Definition of the problem, including current practices. 

II. Visits and discussions with other transmission companies. 

III. Intensive discussions with equipment manufacturers. 

IV. Selection of equipment. 

Around November 1963 it was established that through increased 
automation in the field, the instantaneous transmission of such information, 
by teletype, into a process control computer was possible and economically 
feasible. In our case the economic justification was one of the most 
difficult assignments. Though theoretically no one could argue with the 
mathematics and the fact that all technical people agreed that the savings 
should easily equal the expenditure, it was hard to show it. In this business 
it is impossible to establish a controlled experiment whereby the line is run 
with and without the computer, under the same conditions. The alternative 
was as follows: 

Part of the feasibility study was the creation of a program simulating 
the pipeline. It was a crude version of the eventual process control 
program. We then selected certain events in the past and the decision made 
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by the dispatcher. Then by running the program on an off-line computer, 
we develop the solution. This we found could then be compared with the 
actual facts and its effect on the operation translated into dollars and cents. 

We had little difficulty in showing that even if the computer was not 
used for anything other than such occasional events, we would recover the 
investment. Any additional application would represent extra benefits. 

In spring of 1964 management approved the program and a full 
time implementation group was established. The hardware was selected 
and the delivery set for September 1965. 

The computer selected was the IBM 17 10. We had been using a 
1620 up to this point so changing to a 1710 on a time-shared basis eased 
our programming effort. The computer was a Model II, 60K disk system 
with card I/O and typewriter output to dispatch. In addition, the dispatcher 
could communicate with the 17 10 by a manual entry device. 

This 1710 was replaced by an 1800 after only 19 months, since the 
latter had about three times the core, five times the speed and only rented 
for three quarters of the 17 10 system. 

The conversion was simple since the 1800 programs were all in 
FORTRAN while the 17 10 programs were written in SPS. 

5. Desc ription of Telemetering & Automation 

All 45 compressor stations and three large meter stations are fully 
telemetered and most are remotely controlled from the central dispatch 
office in Toronto. 
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The telemetering works on an exception basis, i.e. no information 
comes in from a station unless an alarm or upset is present at that station. 
An alarm is a change in the status of a unit or the recycle valve. An upset 
is defined as a change of 10 p.s.i. in either the suction or discharge 
pressure. The master telemeter control at Toronto, continuously polls 
each station sequentially to see if there is an alarm or upset there and if 
not, passes on to the next station. If there is, an alarm or upset message 
consisting of all the variables for that station, comes in to the 1800. 

An hourly log is automatically produced on a logger showing the 
suction and discharge pressure, number of units on-line, horsepower and 
flow for each compressor station. 

The dispatcher will eventually have full unit stop/start control at all 
compressor stations. When a unit is turned on or off by the dispatcher, 
the station automatically adjusts itself to this new condition. 

At present there are about 1,000 alarms and upsets coming in to the 
1800 in a 24-hour period. It is obvious that this amount of data does not 
allow the dispatcher sufficient time to analyze each message. One of the 
functions of the process control computer is to filter these messages and 
print out only the significant changes. 

6. Description of Computer Guide System 

The IBM 1800 is composed of a 32K Model II memory, card reader/ 
punch, three disk drives, two remote 1053 typewriters and a decade switch 
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manual entry box. In addition, a special interface /buffer has been designed 
by IBM that accepts the telemetered alarm and upset messages as they come 
in serially by bit , . conve rts them from Baudot Code to internal code, stores 
them in a special buffer and creates an interrupt to the computer when a 
digit has been assembled. 

The system is operated on a time-shared basis in the sense that all 
existing computer applications are run on the 1800 at the lowest priority 
level. These applications include engineering design, gas sales, sales 
forecasting, deliverability of gas wells, etc. 

We are using TSX-3 , Mod. 3 which takes about UK of core. We 
have had very little trouble operating with this system except for minor 
troubles in earlier versions. 

All the process control and most of the off-line programs are stored 
on the disk. In total, there are ten levels of priority within these programs, 
(see list in Appendix). The non-process or off-line programs have the 
lowest priority. Level 4 has been assigned to the manual entry box which 
allows the dispatcher to ask for any data or program from the computer. 
The timed interrupts from the real time clock every 35 seconds, is level 1, 
and the telemetered alarms or upsets , level 0. Hardware interrupt for 
the typewriters, digital inputs and disks fill the intervening levels. 

The following is a detailed description of the various programs 
servicing the system. 
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A . . Alarm/ Upset Program 

This program handles the assembled alarm, upset and demand log 
messages which have been assembled into complete messages by an in- 
core routine called CAEPG, and operates at level 7. CAEPG itself 
operates at level and calls in the Alarm/Upset program after it has 
assembled a complete message. An alarm is defined as a change in the 
status of a unit, recycle valve, generator lock-out or local/ remote 
indicator. As soon as the message stack located in the computer memory 
contains an input message to be processed the Alarm/ Upset program is 
called in after any appropriate lower level has been saved. This program 
then checks the incoming message to determine if it is an alarm or upset. 
If it is an upset it takes all the data that has come in on the upset message, 
i.e. pressures, temperature, flow, number of units on-line and calculates 
horsepower and if it is a turbine station, RPM, Head, ACFM and Surge 
condition. At this point the program checks these variables against 
operating restrictions and if any are violated, types a message to the 
dispatcher telling him the time, station number and the particular offended 
condition. If no violation has occurred, no advice is given to the dispatcher 
in this way many of the needless upset messages are eliminated. 

If the interrupt has been caused by an alarm, the above procedure 
is repeated, but in addition, the particular data that comes in for alarm, the 
status of each unit and position of recycle valve, are checked and the reason 
for the alarm is printed out in English. 
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B . » Timed Interrupts 

There are several programs that can be called in this level by the 
timed interrupt that occurs every 35 seconds. The interrupt is ignored 
until fifteen minutes to the hour at which time a program is called in to 
check if there are any stations that have not produced an alarm, demand 
or upset in the past three hours. If there are, these stations are printed 
out for the dispatcher to call up via a demand log. Although it is perfectly 
acceptable for a station not to alarm or upset in a three hour period, this 
acts as a check to make sure that the station's alarming equipment is 
working, and ensures that these stations will have their computer-stored 
data updated at least every three hours. 

Every hour, an hourly log is printed from data stored internally. 
The suction pressure , discharge pressure, number of units f set point, 
flow, and B.H.P. are logged for each of the stations on the logging type- 
writer. After this has finished, another program is called in that 
computes horsepowers, flows, flowing temperature and pressure, and line 
pack for the entire line. This information is used during the following 
hour in the handling of alarms and upsets. 

At eight o'clock in the morning a complete statistical report is 
produced showing the horsepower hours, operating and standby fyours for 
each station, the number of alarms, upsets and false alarms and change 
in line pack for 24-hours . 
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C. Manual Entry Unit 

The dispatcher can call for either data or a program from the 
computer or enter data into the computer via his 1077 manual entry device 
consisting of twelve rotary decade switches and an interrupt button. For 
example, if he wishes to know what the horsepower is at a station, he dials 
the station number and a two-digit code specifying horsepower, presses 
the interrupt button, and if higher level programs are not running, will 
receive the horsepower within three seconds on the typewriter. 

If he wishes to change say a sales volume at a particular point in 
the data stored in the computer, he will dial a sales code, pipeline section 
number and the new sales volume, press the interrupt button and the data 
will be entered into the disk. 

He can also call the simulation/ optimization program at any time he 
wishes, by dialing the particular code for that program. He would 
probably do this at the occurrence of a major disturbance to the line such 
as a station or large horsepower unit suddenly dropping off-line. This 
program may take up to five minutes to run depending on the number of 
alarms and upsets which occur and also the complexity of the pipeline due 
to the non- avail ability of horsepower. 

D. Simulation and Optimization Program 

The heart of the process control system is the simulation and 
optimization program mentioned above. This program is called in by the 
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dispatcher via the manual entry device to scrutinize pipeline conditions 
and determine if there is any way to improve its operation. 

The simulation program uses an iterative procedure that increments 
the flow into the line by 5 million cubic feet, using the existing flow as the 
starting point. With each increment in flow, the program proceeds down 
the line computing pressure drops, and determines if there is adequate 
horsepower available to handle the additional flow. The initial increment 
of 5 million cubic feet is doubled with each iteration. Eventually after 
several iterations, there comes a point at which the line is incapable of 
handling additional flow. The program then decrements the flow by one- 
half of the last increment and tries this amount down the line. If this 
proves successful, another half again is added and so on, until the difference 
is down to 2 million cubic feet. This process is quickly convergent, an$ 
the whole process takes about six minutes on a Model II 1800. When the 
final flow has been determined, a check is made to ascertain if any 
minimum RPM or Surge restriction has been violated. If so, corrections 
are made to the stations in question and a final pass determines if the flow 
has to be reduced slightly to compensate for these adjustments. 

The final output to the dispatcher consists of a list of compressor 
station's settings to be used to achieve efficient running line conditions. 
The dispatcher has to use his judgement as to what order to change the 
horsepower, and whether to do so at all, if he knows of a particular line 
condition coming up that is unknown to the computer which would negate 
its instructions. 
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The dispatcher can call in the simulation /optimization program to 
solve a hypothetical problem such as: how should the line be set up to 
handle the shutdown of a particular station that is going to occur tomorrow 
due to maintenance? In this case, he can dial in the station that is going 
to be shutdown, plus any other pertinent information, call in the program 
and get his answer within five minutes. 

7 . Conclusions 

Here is what we have achieved. For a relatively small incremental 
cost we have successfully entered the process control field. Without any 
reservation we are satisfied that we have met the original target. We know 
that we have saved in fuel requirements. The computer has provided 
guidance to the dispatcher which in turn resulted in higher throughput. It 
would be rather difficult to pinpoint exactly how much of this extra throughput 
is due directly to the process control system due to many inter-related 
factors. Whatever the inter-relationship we are satisfied that it is higher. 
In addition we have derived the following extra benefits: 

We have a hardware system capable of accommodating large and 
sophisticated programs to be used by other departments in the 
company. Our Engineering department uses it several hours a 
day for pipeline design. 

We have a competent and active group trained in the disciplines 
required for a successful development of advanced scientific 
application. 
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Protection of facilities against hazardous operation by scanning 
and informing the dispatcher when a station does not respond. 

We learned new facts about our system. Installing a computer 
system forces one to think more deeply about your operations. 

Faster preparation of reports on daily operating conditions and 
immediate corrective action. 

Management can reach decisions on quantitative facts presented 
in real time, instead of after the fact. 

Plan a better maintenance shutdown schedule . 

Closed loop which is theoretically possible now, is a possibility. 
For the time being we are not investigating this aspect for a number of 
reasons, the most important of which is safety and the fact that reaction 
time is not critical in our operations and hence closed loop would be 
difficult to justify financially. 

Thank you. 
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APPENDIX 



Interrupt Levels 



Levels 



Bit 
Position 



1 
2 
2 
2 
3 
3 
3 
3 
3 
3 
3 
4 





1 
2 

1 
2 
3 
4 
5 
6 




Device, 

Tel. Interface 
(CAEPG) 

Time Interrupt 

2310-1 

2310-2 

2310-3 

TYP-1 

TYP-2 

TYP-3 

1442-1 

1442-2 

DAO 

DI 

1077 



Console 



Type 



User 



TSX 
TSX 
TSX 
TSX 
TSX 
TSX 
TSX 
TSX 
TSX 
TSX 
TSX 
User 



TSX 



Recognize interrupts - Call 
Level 7 for all reading and 
analysis . 



Recognize interrupts - CalV^A 
Level 9 for reading and 
analysis . 



LEVLV 
Console 
Manual Entry 



User 
User 
User 



Called by Level 0. 

Call QUEUE Program(CONSL) 

Called by Level 4/0 - for 

reading dials and all 

analysis. 
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Out of Core 
Inte rrupt 



User 



Type message . 
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Keyboard 



User 



Call Intex. 
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SYSTEMS AND PROGRAMMING PROJECT MANAGEMENT 

The allocation of limited systems and programming 
resources to the highest payoff areas is becoming more 
important as data processing installation costs continue 
to rise. Long and short-range plans properly approved 
by top management and formalized systems project manage- 
ment are vital tools to assure that systems capability 
is focused on the major areas of the enterprise and ade- 
quately controlled to attain the stated objectives. To 
work effectively in this environment, additional demands 
are placed onto the systems group to develop systems plans 
in terms easily understood by top management and onto 
data processing management to bring about fulfillment of 
the approved plans on time and as economically as possible. 



Ralph B. Sackman, Jr. 
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ORGANIZING FOR MAXIMUM COMPUTER RESULTS 
By Ralph B. Sackman, Jr. 

A typical goal of many organizations today is to use a com- 
puter to provide information for more effective management of the 
enterprise. In the. eyes of management the computer has passed 
through the trial stage, which has tended to restrict its usage to 
record keeping activities in the past, and third generation equip- 
ment has been developed with far more capacity and flexibility than 
was previously available. Bui; more than management approval and 
computer equipment capacity is needed to achieve maximum computer 
results for the entire organization. 

The first step is to eliminate "fire fighting" that can ab- 
sorb most of the available system 1 s A programming resources. This 
can be accomplished by formalizing responsibilities within the data 
processing area and by establishing a standard method for computer 
users to request program changes and other services. The timely 
and accurate reporting that results from a well organized data pro- 
cessing function builds confidence in the ability of systems and 
programming people to assist in solving problems in other parts of 
the organization. 

The next step toward achieving maximum computer results is to 
assure that new systems are relevant to the interests of management. 
An approach toward this end would include a top level management 
steering committee to direct the overall data processing program. 
Effective communication between the steering committee and the systems 
group, including development of a long range plan, assures mutual 
understanding of management interest and expected system performance. 



An example follows of the specific actions that could be 



taken to formalize responsibilities in an existing computer opera- 



tion and to expand computer usage. 



EXISTING OPERATION 



A large number of program maintenance tasks could remain 
after the conversion of a large application. An inventory should 
be taken of the maintenance items and a short term schedule publish- 
ed citing the task description, the requester and the approximate 
time to complete. The schedule would enable the supervising pro- 
grammer to ascertain priorities and assign the work on a systematic 
basis to his staff. A request for data processing services form 
should be put into effect simultaneously with the short term schedule 
for use by interested parties in requesting additional maintenance 
programming work. Verbal requests for programming work should be 
discontinued. 

Other procedures should be put into effect to make formal the 
communication between the programming unit and computer operations. 
Verbal requests for services from or instructions to computer opera- 
tions personnel from the programming unit should be discontinued by 
means of two rather simple forms. One is a transmittal letter for 
requesting computer room services, including the keypunching, assem- 
bling and testing of programs and other related tasks. The second 
transmittal letter is to send new or revised object programs to the 
computer operations supervisor. He would utilize this document to 
assure adequate program library maintenance and to inform the computer 
operators of changes to programs. Formalizing the communication in 
this manner would reduce the misunderstandings between the programm- 
ing unit and computer operations.' 
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Computer operations could meet the servicing needs of the 
programmers while maintaining production schedules by establish- 
ing priorities for compilations and testing. Only vital produc- 
tion jobs should carry a priority higher than program, compilations 
and testing. Programmers should receive the results within a few 
hours and carry on with their work without lost time. Through 
this procedure the computer users should receive good service on 
their requests for modifications and difficulties should not be 
experienced in meeting existing production schedules. The computer 
operators should run all program tests and assemblies utilizing 
written instructions submitted by the programmers. Keypunching of 
programs should also be handled under a priority procedure where a 
priority one would require immediate attention of the keypunch 
operator and a priority two would require return of the punched 
cards and coding sheets within forty-eight hours of receipt. 

The librarian functions within the computer operations unit 
should be assigned to a single individual. That person would main- 
tain the program object deck library utilizing the object deck trans- 
mittal forms from the programming unit. Programmers or other indi- 
viduals should not be permitted to insert or delete object programs 
from the library. The librarian should update the computer setup 
and run instructions to notify the computer operators of changes 
in operating procedures brought about by the program revisions. The 
single .responsibility concept should also be utilized in maintain- 
ing the magnetic tape library. Only the librarian should be per- 
mitted to select tapes from and return tapes to the library. 



A reporting system for computer utilization and scheduling 
should be developed. The reports should include program efficiency 
statistics which would show the number of program tests and compila- 
tions provided to each programmer. The results would indicate the 
problem of excessive computer runs caused by inaccurate coding. 
Utilizing this information, the supervising programmer could discuss 
performance in specific terms with each of his programmers. Other 
reports should show computer time spent on production runs by appli- 
cation area. Computer time trends should be charted to foresee any 
need for additional equipment. or a modified configuration. Machine 
loading would be leveled by means of a monthly forecast of computer 
time which would portray days that are overloaded. The computer 
operations supervisor would utilize this report to rearrange sched- 
ules, where possible. 

Programming standards should be developed to assist in main- 
taining the quality of work ±rt a high level production in the pro- 
gramming unit. Standard methods and documentation permit the 
assignment of program maintenance to junior programmers, thus re- 
leasing for other new work the programmers who originally wrote the 
programs. Approval for departure from the standard methods should 
be obtained from the supervising programmer. The standards should 
be 'reviewed regularly to insure that they are up to date, realistic 
and useful. Preparation of standard program documentation prevents 
misunderstandings by maintenance programmers . and by computer opera- 
tors responsible for the proper usage of the program. Thus, the 
program maintenance and program running tasks should become routine 
functions that do not require substantial time of systems and pro- 
gramming personnel assigned to new areas. 



NEW AREAS 



Attention should next be focused on the way to organize the 
systems effort for work on new long term projects. Definition and 
selection of future projects often is not as obvious as the original 
application that justified the computer. The justification of cer- 
tain projects would be based largely upon intangible benefits 
rather than reduced clerical workload, reduced accounts receivable 
float or improved customer service. To provide continuing assurance 
that the systems and programming group is working on the right prob- 
lem, a management steering committee should be appointed by the 
president. The committee's broad function should be to evaluate 
planned systems projects and establish priorities. 

Soon after appointment of the steering committee, the data 
processing group should prepare a tentative long range schedule 
showing the major areas of computer usage. The long range schedule 
should be submitted to the steering committee with the understanding 
that systems planning reports would be furnished to the committee 
prior to final approval on any new project. The systems planning 
reports would show the changes required to improve the flexibility 
of existing systems, the recommended sequence of projects and the 
approximate costs. The reports would be written in business termi- 
nology and make little, if any, reference to the computer itself. 
The steering committee would review the reports to assure that the 
proposed results are relevant to needed management information and 
to satisfy itself that the results are worth the conversion costs. 
Upon approval the steering committee would request that appropriate 
persons be assigned to a project team to work with the systems analyst 
to develop a detailed systems design. 



With multiple systems projects in progress, effective project 



management is essential. The data processing group should operate 
under the project leader concept where one person is responsible 
for a project from the systems planning phase through to the time 
that all programs are operating successfully in production. The 
project leader would be responsible for estimating the completion 
date, scheduling all required activities, and recommending the pre- 
cise boundaries between his project and others. Each project leader 
would report monthly as to his progress against plan and .would state 
problems he has encountered that are beyond his control. Programmers 
would be assigned to the project leaders based upon demonstrated 
need. Project backlog should be documented at all times. 

The project leaders would work in partnership with designated 
operating personnel toward realistic and economical systems design 
in new areas. The operating personnel would approve the systems de- 
sign as it affects their operations and the systems project leader 
would develop the detailed plan to meet the desired criteria. The 
management steering committee should be kept informed of progress 
through minutes of meetings and should review the objectives and 
their values prior to implementation. 

A significant advantage in reducing "fire fighting" and es- 
tablishing a reporting relationship with top management is the 
salutary effect upon the esprit de corps of the systems and pro- 
gramming group. Personnel in the group know what projects are ahead 
and realize that consideration of the backlog and work in progress 
is considered thoroughly prior to a decision involving a change in 
direction. Each of them would be assured of participating in a 
worthwhile project. In addition there is little chance that per- 
sonnel would be pulled off a long term project to correct a day to 
day reporting or control problem. 
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In summary, formalizing the present operation would make 
intelligent assignment of personnel possible. Appointment of a 
management steering committee and the systems planning concept 
would. assure that new long term projects attack the largest pay off 
areas first. There would be a mutual understanding between manage- 
ment and the data processing group as to where the data processing 
effort stands today and where it is going. Ultimately, the customers 
and stockholders would benefit because effective computer usage would 
enable management and employees to do a better job. 
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December 20, 1967 

To: Members of 1620 Project Section COMMON Users 

From: Tony A. Ross and Richard D. Ross, Co-chairman 1620 
Project Section 



As I promised in San Francisco, enclosed you will find a copy 
of the names and addresses of all 1620 USERS registered at the 
San Francisco meeting along with the comments that each of you put 
on the sheet that Richard passed out at the first meeting. Please 
read these comments carefully and if you can help any of your 
brother-members in any way, please contact them on an individual 
basis . 

I noticed that many of you were interested in some items and 
upon compiling the list I found that someone else had been doing 
work in this particular area. So maybe with a lot of correspondence 
back and forth, we can be of help to each other. 

I just finished a letter to Dr. Jardine suggesting that he 
send a copy of the Kingston compiler directly to me and I, in turn, 
will send each of you a copy if you are interested. As soon as 
he answers my letter and sends a copy of the processor, I will then 
write to each of you, and you may request a copy from me. Do not 
let this deter you from writing directly to Dr. Jardine if you so 
desire. 

I am also in the process of completing the copying of the 1620 
Newsletter and as soon as these are completed, I will mail these 
to each of you that specifically requested the remainder of the 
Newsletter . 

Keep in mind our next COMMON meeting to be held in Chicago 
April 8-10 at the Pick-Congress Hotel. 1 will be glad to accept 
any abstracts or papers you would like to present now. I think 
the meeting in San Francisco was very informative and useful to 
each 1620 User that attended. Let us all work together to make the 
meeting in Chicago even more useful and this can only be done with 
the cooperation of everyone. 

Since it was suggested that some. papers be given on how to 
write or modify compilers, I am especially interested in papers of 
this nature. Although, any useful paper will be accepted. If any 
of you are doing work in the CAI area, I am sure that this would 
be of interest to the Users that attend the Chicago meeting. 

I want to use this letter to personally thank each of you for 
attending the meeting and. making it the success that it was. I 
especially would like to thank the ones of you who presented the 
very useful papers that were given. 



Again, let me remind you to be thinking about papers and 
send any information that you have that might help for the 
Chicago meeting. 

I hope that each of you had a Merry Christmas and a very 
Happy New Year. 



Yours tru^Ly 

Tony A. Ross and Richard D. Ross 
Co-chairman 1620 Project Section 



P.S. Don't tell me about "sunny" California anymore. I almost 
froze to death the whole time I was there. 



A. Moore, W. T. 

Presently awaiting delivery of Monitor I system 
1620 Mod-1, 40K, 2-tapes 
1443 Printer and Disk 



B. Streeter, T. D. 
Model 1, 40K 



C. Sloboda, J. 

1620 Mod-1, 20K 

Interested in obtaining help on modifying processors 



D. Brummer, Bro. Elmer 
1620 Mod-1, 20K 

Interested in COBOL compiler for 162 



E. Schrader, H. C. Mrs. 
1620 Mod-1, 20K 

Have made modification to PDQ compiler 
Have -precompiler for PDQ FORTRAN 



F. Sward, R. W. 

1620 Mod-1, 20K, 2-1311, 1443, Teleprocessing working on 

1. Computer assisted instruction 

2. Computer based councelling 

3. Student scheduling 

4. Student transcript processing 

Interested in DATA SPS for 20K - 1620 



G. LaRue, Richard 

1620 Model I, 40K, 1 Disk, Printer 

1. Interested in obtaining: 

a. Kingston FORTRAN 

b. DATA SPS 

2 . Can Contribute 

a. Test analysis program using 12 30 optical scanner 

b. Tabulation and cross tabulation program for 
Questionnaire and Survey Analysis,- 



c. Medical (or other graduate college) school admissions 
evaluation system 

d. Student Scheduling Programs 

e. Alumni Processing X 

f. SPS SORT routines available for FORTRAN 




Fricke, E . C. 
1620 Model 1, 20K 
1. Interested in 

a. Student use of 1620 

b. Student scheduling on 1620 

c. Batch processing 

d. Precompiler for PDQ' 



Goldstein, J. H. 

1620 Model II, Disk Drive, 40K, Paper Tape Input 
1. Need 

a. Information on Data SPS for 40K 



Lahners, E. L. 

1620, Model I, 20K, 1621, 1622, 1624, 1626, 1627 

1. Need PDQ for plotter 

2. Processor Available 

a. FORTRAN 

b. PDQ FORTRAN 

c. FORCOM 

d'. PDQ-FORCOM 
e. NCE 

3. Programs Available 

a. Payroll 

b. Engineering manpower, cost analysis 

c. Pharmacy drug cost accounting (patient, service) 
• d. Statistical programs 

e. Neutron Activation Analysis (Simplex Method) 

f. Registration (patient Record information Retrieval) 

Jones, C. E. 

1620 Model I, 40K, 1443 Model 2 (on order), 1 Disk 
1. Need information on Kingston FORTRAN for Disk with 
and without printer 

Jones, C. E. 

Model I, 40K, with p Disk and Printer 

1. Interested in re-read for . FORTRAN II and save paper 
for Monitor I 



Emerson, J. T. 

Model II, 2 OK, with 1 Disk and no printer 

1. Interested in Data SPS, 20K, Version and Compiler 
modification (10 cards) 

2. Can contribute: 

a. Program that reads Porta punched cards for FORTRAN II D 
program 

b. Program to punch a contour map in 9 densities 

c. Program interrupt - runs large program until start 
button is depressed, then the large program is stored 
on the disk and the smaller program is processed. Upon 
completion of the smaller program, the larger program i 
then brought off the disk and continues to run. 
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For information on items 1-3 contact 
H. Miller 

Fresno State computer center 
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INTRODUCTION 



This paper describes a batch processing FORTRAN system, written at 
California State College at Hayward, for a 20K, card system IBM 1620 
computer. The system is designed to increase throughput and introduce 
larger system concepts in a student oriented installation," 

The primary characteristics of the computing environment at Cal-State • 
are 

1. A large number of fairly short FORTRAN programs which have 
a fast turnaround requirement during periods of heavy 
computer usage. (These are computer class assignments.) 

2. A lesser number of FORTRAN programs for classes such as 
chemistry and physics. These can be run during off-hours 
in a "closed shop" environment. 

The most important factors contributing to efficient utilization of 
computer time and student time during the prime hours of class usage 
are 

1 . Source Language Error Detection 

Most 162 card system compilers have limited error checking 
and will not detect source language errors. These execution 
errors are costly in terms of student and assistant time. 
Most students require assistance in diagnosing errors, and 
machine debugging in such cases is both difficult and time 
consuming. 

2 . Decreased Deck Handling and Loading 

In an environment where there are many short programs to be 
compi-led and executed, the time spent in loading the compiler 
and subroutines can easily become the most significant machine 
time factor. Efficient use of batch processing techniques can 
greatly increase the total throughput and also provide fast 
turnaround for any particular job. 

Another important consideration in a system oriented toward programming 
instruction is the compatibility of the system with larger computer 
systems.. It is desirable that the language used be consistent with 
FORTRAN'S found on larger systems, and that it contain as many basic 
FORTRAN features as possible. 

The C.S.C.H. FORTRAN system, designed to satisfy the requirements of 
fast throughput and larger system compatibility, is based on the PDQ 
FORTRAN system. The PDQ compiler was chosen because it has the shortest 
compile time and produces smaller and faster executing object programs 
than any 2 OK card system compiler available at the start of the project. 
In addition, the PDQ FORTRAN language appears to be the most advanced of 
the available 1620 FORTRAN^ with features such as" extended FORMAT capa- 
bilities and COMMON and . PROCEDURE statements. 
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The PDQ system has two major drawbacks, however. Source language 
error detection is minimal, and is unsatisfactory for use in a 
teaching system. In addition, the subroutines must be separately 
loaded with each object deck. This constant loading becomes quite 
expensive when a large number of short programs are to be run. 

The C.S.C.H. FORTRAN maintains the speed and language attributes of 
PDQ while reducing these disadvantages. The three principal compo- 
nents in the system are: 

1. FORTRAN Precompiler ; 

Since the level of error detection required could not 
be provided in the compiler, a separate precompiler 
was written which provides a high level of error 
detection. The total time — both student and machine — 
required to produce a working program is greatly reduced 
in this manner, since the previous compile-execute-debug 
phases necessary to find one error is replaced with a pre- 
compiler phase which detects multiple errors. 

2 • FORTRAN Compiler : 

Some additional features have been added to the PDQ language 
and some modification and deletion of existing statements (^j 
made. Statements are included that provide communication 
with the batch processing execution monitor. 

3 • Subroutines and Batch Processing Monitor : 

A monitor has been added to the subroutine library which 
allows batch execution with only one loading of the sub- 
routines for any number of stacked execution jobs. Job 
card control, FORTRAN calls to the monitor, output line 
counts, program timing, program linking facilities, and 
continuous no halt execution of programs are features 
provided by the monitor. 

Both the compiler and precompiler operate in a batch processing mode 
under control of JOB cards. This means that any number of programs 
can be processed to execution in three phases with only one loading 
of the precompiler, compiler, and subroutines, and no halts aside 
from the loading process. The procedure is indicated in figures 1, 
2 , and 3 . 

The entire system is card oriented, and no typewriter input or listing 
of source statements is allowed. It is also possible to suppress type- 
writer output at execution (by using a monitor option) in order to 
achieve faster throughput. 
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Execution Subroutine Configuration 



One of the undesirable features of the ~PDQ . system, as well as other 
162 FORTRAN systems, is the requirement that the subroutines be re- 
loaded for each object deck. This procedure is necessary so that the 
functional subroutines (SIN, COS, etc.) used by the program can be 
relocated behind the object program. The execution configuration is 
illustrated in Figure 4 . In the environment discussed, however, the 
optimization of core storage provided by including only the subroutines 
required for a particular program is not as important a factor as the 
time required to load the subroutines with each program. 

This reloading of subroutines can be eliminated at the cost o± storage 
space by keeping all of the subroutines in core at the same time. 
Programs can then be loaded behind the subroutines into a fixed location. 
This configuration is shown in Figure 5" . It has been found that the 
"variable core" remaining for object programs in this system is adequate 
for practically all programs in the student environment. This "student 
version" also allows the batch "execution of object programs under control 
of a monitor subroutine. 

There are three execution subroutine configurations possible. These are 
specified to the compiler by a field on the JOB card. The compiler 
origins the object programs to load into the proper location. The 
configurations are - (f^, 



1. Basic Student Version: 

The following functional subroutines are included: SIN, 
COS, SQRT, LOG, EXP, ABS . Object programs begin at 
approximately 09600. 

2. Expanded Student Version: 

This consists of the basic set plus ATAN and DRH routines. 
Object programs begin at approximately 10500. 

3. Original Relocatable Version: 

Object programs begin at approximately 07400. 

Option 3 is rarely required since most programs can be batch executed 
in the student version. The same subroutine deck can be used for either 
of the student versions. 

Execution Monitor 

The monitor provides batch execution capabilities by loading the next 
program stacked in the card reader when certain, end-of -program condi- 
tions occur. The start of programs in the input stream is defined *>y#^ 
a JOB card. The automatic loading and executing of the next stacked ^ 
program is initiated by any one of the following: 
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1. Execution of a CALL LINK or CALL EXIT statement: 

These statements functionally terminate a FORTRAN program/ 
The primary difference between the statements is conceptual. 
CALL EXIT terminates a job and CALL LINK is used together with 
COMMON to link overlay phases of a program* 

The overlay of a program can be profitably used to conserve 
core in large programs. For example, all program variables 
can be put in COMMON and initialized in a phase which is then, 
overlaid by the main program. Figure 6 illustrates the source 
deck arrangement for this example. 

2. Reading of a JOB card: 

An attempted READ of a JOB card by the FORTRAN program will be 
treated as an end-of-file condition for the input to the program. 
This will cause the monitor to branch to the specified statement 
if an ON ENDFILE statement is used or to terminate the job and 
cause loading of the next program. The ON ENDFILE statement is 
described later. 

3. Execution of an END statement: 
For those who forget a CALL EXIT. 

4. An -Input Data Error 

An input error will be considered a job terminating error" unless 
an ON DATA ERROR statement is used. This statement is further 
described under the FORTRAN compiler. 

5. A Console 'Interrupt': 

Pressing INSTANT STOP, RESET, INSERT, RELEASE, and START at any 
time during execution will cause the current job to be aborted 
and the next program found and loaded. 

6. Line Count or Times Overflow: 

These will be described below. 

A separate termination message is typed by the monitor for each of these 
end-of-job conditions. The JOB card is also typed for each job. 
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The PDQ system has two major drawbacks, however. Source language 
error detection is minimal, and is unsatisfactory for use in a 
teaching system. In addition, the subroutines must be separately 
loaded with each object deck. This constant loading becomes quite . 
expensive when a large number of short programs are to be run. 

The C.S.C.H. FORTRAN maintains the speed and language attributes of 
PDQ while reducing these disadvantages. The three principal component 
of the system are ' . 

1. FORTRAN Precompiler 

Since the. level of error detection required could not be 
provided in the compiler, a separate precompiler was 
written which provides a high level of -error detection. 
The total time — both student and machine — required to 
produce a working program is greatly reduced in this mariner, 
since the previous compile-execute-debug phase- necessary to 
find one error is replaced with a precompiler phase which 
detects multiple errors. 

2. FORTRAN Compiler 

Some additional features have been added to the PDQ language 
and some modification and deletion of existing statements 
made. Statements have been included that provide communica- 
tion with the batch processing execution monitor. 

3 . Subroutines and Batch Processing Monitor 

A monitor has been added to the subroutine library which 
allows batch execution with only one loading of the sub- 
routines for any number of stacked execution jobs. Job 
card "control, FORTRAN calls to the monitor, output line 
counts, program timing, program linking facilities-, and 
continuous no-halt execution of programs are features pro- 
vided by the monitor. 

Both. the compiler and precompiler operate in a batch processing mode 
under control of JOB cards. This means that any number of programs 
can be processed to execution in three phases with only one -loading 
of the precompiler, compiler, and subroutines. The procedure is 
indicated in Figures 1, 2, and 3. 

The entire system is card oriented, and no typewriter input or- listing 
of source- statements is allowed. It is also possible to suppress type 
writer output during execution (by using a monitor option), in order to 
achieve faster throughput. 



FORTRAN Compiler ^1 

The compiler is essentially the PDQ FORTRAN compiler with the following 
modifications designed to increase language and batch compiling capabi- 
lities: 

1. The compiler has a batch compiling option which suppresses 
the halt between jobs. A card with eighty asterisks is 
punched following the trailer cards for an object deck. 
This permits easy separation of object decks when batch 
compiling with no stops. 

2. A JOB control card must precede each source deck. The 
JOB control card will be recognized by- the compiler and 
typed to provide a record of jobs. The JOB card also 
contains compile options that specify execution subroutine 
configuration. 

3. All source input to the compiler is from cards. Also, no 
typed listing of the source deck or symbol table is allowed, 
although the symbol table can be punched alphamerically . 

4. Subroutines cannot be compiled into the object deck. 



5. Almost all error detection has been eliminated. A program 
with no precompiler errors will compile correctly, however. 

6. The following statements have been added to the PDQ language: 

a. ' CALL nnnnn 

where nnnnn is a five digit memory address. This generates 
a BTM instruction to the address specified. The operand is 
the return address to the -calling program. This statement 
is used for communication with assembly language subroutines. 

b. IF (SENSE LIGHT n) S lr S 2 
SENSE LIGHT n ON 

SENSE LIGHT n OFF 

where n is a single digit number and Si and S2 are statement 
numbers. The IF statement is similar to the IF SENSE SWITCH 
statement except that it tests an internal logical indicator. 
The test does not turn off the " senselight" . The other two 
statements are used- to set the ten indicators. 

Since the senselights are internal indicators and require no 
core storage, i:heir use will require less object code and 
symbol table space than the use of arithmetic variables as 
indicators. 
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c. 



CHECKPOINT nnnn 



This statement is the same as the STOP statement except 
that the program does not halt after typing the specified 
number. This has been found to be a useful logic flow 
debugging aid without the slow execution typeout dis- 
advantages of TRACE. 

d. ON ENDFILE GO TO S-^ 

where is a statement number. This statement specifies . 
the number of the statement to be executed when the last 
data card has been read. - This condition is defined by the 
last card indicator or the reading of a JOB card. The 
statement can be placed anywhere in the program but must 
be "executed before the end of file condition occurs. If 
this statement is missing, the reading of a JOB card will 
terminate the program and cause execution of the following 
stacked program. 

e. ON DATA ERROR GO TO S x 

This is similar to the ON ENDFILE statement and specifies 
a program entry point if an input conversion error is 
detected. An input error will terminate the job if this 
statement does not precede the occurance of the error. 

f . . CALL EXIT and CALL LINK 

These are described under the batch processing monitor. 

The PAUSE and CONTROL statements have been deleted from the language and 
the syntax of Procedure Statements has been changed. 



FORTRAN Precompiler 

The FORTRAN precompiler is a one pass error checking program which 
executes at approximately the same speed as the compiler. JOB card 
recognition and batch processing capabilities are included. Some of : 
the major features of the precompiler are 

1. As far as is known, all non-logical checkstop errors are 
detected. Execution errors such as a calculated subscript 
going out of bounds are, of course, undetected. 

2. A large number of separate diagnostics (approximately eighty) 
are provided. Errors are identified by a two digit number 
which is typed out along with the statement containing the error. 



In addition to controlling the initiation and termination of programs 
in a batch execution mode, the monitor also provides optional monitor 
functions during the execution of a program. The features provided areLV 



1. Output- Line- Count Monitoring: 

The number of output lines allowed is specified on the 
JOB card. If this limit is exceeded, the job is aborted. 

2. Suppression of Typed Output: 

A TYPE or PRINT statement will execute as a PUNCH statement. 
This results in considerable throughput increase in a batch 
processing environment. JOB cards are. punched when en- 
countered in order to easily separate output when listing 
the cards from a series of jobs. Because of the construction 
of the JOB card, a 407 board may be easily wired to cause 
ejection to a new page when a JOB card is encountered during 
listing. 

3. Suppression of STOP Statement: 

In order to maintain the no-stop, batch processing concept, 
the halt of a STOP statement may be suppressed. 

4. Execution Time Monitoring: 



Since the FORTRAN compiler produces very little in-line code ^ 
and practically all operations are performed by a few basic 
execution subroutines, it is possible to provide software 
execution timing capabilities. This is done by placing code 
in fifteen basic subroutines which will increment a software 
timer by an amount proportional to the length of time required 
to execute that subroutine. This will increase the execution 
time of such a subroutine by 240 ,us if the time monitor is 
disabled and by 1040 //s if the monitor is operative. The 
total increase in execution time has been found to be less than 
3% if the time feature is not used and approximately 15% if the 
timer is used. The software time count has been found to be 
accurate to within 10% of the actual time with one-tenth of a 
minute accuracy. 

The maximum time limit is specified on the JOB card and overflow 
is considered a terminal condition. The timer feature is pri- 
marily used in closed-shop, batch processing operations where 
quite lengthy jobs are often run". 



All of the above options are enabled or suppressed by sense switch settings 
when the subroutines are loaded. 





3. Multiple errors in one statement can be detected. This 
reduces the number of precompiler passes necessary to 
produce an error free program. 

4. Error checking is to a higher level than is required by 
the compiler in order to produce valid code. For instance, 
key words are generally identified by only one or two letters 
in the compiler but are checked for six letters in the pre- 
compiler. 

Some of the major errors detected are 

1. Possibly undefined symbol 

Any variable which haa not been defined in a previous statement 
(in terms of card order, not logical flow) will be typed out as 
a possible undefined symbol when it is used. This procedure 
catches most undefined symbols. Statement numbers which are 
undefined at the end of the program will be typed out. 

2. Branch to FORMAT Statement 

3. Duplicate Statement Numbers 

4. All DO Loop Errors 

These include overlapped DO loops, modification of DO para- 
meters within the loop, end of theloop is previous statement, 
etc . 

5. All Subscripting Errors 

These include contradictions involving the number of subscripts 
- ©n a variable and complete checking of subscript structure. 

6. All FORMAT Errors 

7. All Procedure Errors 

8. I/O Statement References non-FORMAT Statement 

9. Exponentiation of Fixed Quantity 

10. All Syntax Errors : (misplaced commas, etc.) in" Other Statements 

In addition, some logical errors and some potential errors such as program 
possibly too large are detected. 




The precompiler symbol table is the same size as that of the compiler 
so that compiler symbol table overflow conditions can be detected. ^ 

The following special implementation restrictions exist but, aside from 
the first, they have no practical implications in our environment: 

1. A FORMAT statement must precede the first I/O statement 
to reference it. 

2. Maximums of three continuation cards, five nested DO's 
and five levels of exponentiation are allowed. 

3. A maximum of twenty symbols can be undefined at any time. 
The important known flaws in the precompiler are 

1. There is no way to detect all undefined symbols in a general 
program. The likelihood of undefined symbols at execution 
causing checkstops is reduced, however, because the monitor 
fills in the unused core with fixed point constants. This 

- produces invalid results in the case of an undefined symbol 
but prevents the subroutines from being destroyed by the 
Transmit Field instruction. 

2. The appearance of a variable in- a DIMENSION statement causes 
that variable to be considered defined. 

3. Arguments of functions are incompletely checked but, this will 
not produce checkstop errors. Mixed mode expressions in the 
argument will be detected. 



ABSTRACT 



The following describes and addition to the programming system for the 
IBM 1800 computer. The expanded system will support up to 16 remote teletype 
terminals being used in a time-sharing environment primarily to solve real- 
time information processing problems. 

INTRODUCTION 
1800 Hardware 

The 1800 CPU makes extensive use of hardware interrupt levels and 
data channels to operate its standard data processing I/O equipment. In 
addition the 1800 can have analog and digital I/O capable of communicating 
directly with almost any kind of equipment. The terminal system uses 2 
words of digital input and 1 word of digital output (16 bits/word) to 
control all 16 terminals simultaneously. No data channels or additional 
hardware are employed. 

TSX Programming System 

The 1800 programming system provides many conveniences. Programs are 
of two types, process and non-process. 

Process programs can be initiated by externally generated interrupts 
or can be queued by any program for execution. They can be a part of the 
system skeleton which is in core at all times or they can be kept on disk 
in core -image form. Process programs have highest priority and generally 
use some analog or digital I/O. 

Non-process programs ordinarily do not use the process (analog and 
digital) I/O. They are usually stacked jobs of a conventional type to be 
run under the non-process monitor. 

When time-sharing, the system does the following: 

(1) . Rurs non-process programs for background (job shop). 

(2) . Periodically checlsthe queue for process programs. 

(3) . PermitB externally or internally generated interrupts to 

load and execute process programs at any time. 

Both (2) and (3) require that the non-process job be saved and restored when 
the process work is finished. 

The Terminal System 

The terminals extend the time -sharing capabilities of the system by 
allowing up to 16 users to communicate with the system simultaneously. 

Terminal activities ^nclude: 

(l). Queing process programs for execution. 
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(2) . Communicating with programs during execution. 

(3) . Programming in NUtran (conversational fortran). 

Many other activities are planned. 

Most of the terminal system capabilities are achieved by simply making 
the standard TSX functions more accessible. The only programming efforts 
unique to the terminal system are the communications controller (simulated 
by an in-skeleton program), and the time-slicing of terminal service pro- 
grams. 
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